FESCo Proposal for blocking older version of autoconf & automake

[Ralf Corsepius]

On Mon, 2008-05-05 at 12:33 -0400, Christopher Aillon wrote:
> On 05/05/2008 12:21 PM, Ralf Corsepius wrote:
> > On Mon, 2008-05-05 at 12:06 -0400, Christopher Aillon wrote:
> >> On 05/05/2008 11:48 AM, Ralf Corsepius wrote:
> >>> This step is way over due. It also will teach maintainers not run the
> >>> autotools while building.
> >> It will also teach maintainers not to use Fedora for doing upstream work.
> > 
> > How comes you expect each and every tool in Fedora but the autotools to
> > be "current".
> > 
> > We have current compilers, current python, current perl, current ...
> 
> New compilers affects what's in the package.  This affects users.
> New python affects the behavior of the package.  This affects users.
> New perl affects the behavior of the package.  This affects users.
> 
> New autotools affects next to nothing.
The autotools are in the same boat as compilers.

Compiler changes break existing code, autotools changes break existing
code. Both issues affect source code (configure.in/ac, rsp. *.c/*.c++)
and need to be fixed therein.


>   Only what configure.in and 
> Makefile.in look like.  This has zero impact for users.
Both, a compilers user as well as an autotool's users, is the developer.

In an ideal world, a Fedora package maintainer should not have to touch
any of these sources, neither *.c, *.c++ nor *.am or *.ac.

> > You are measuring by double standards - If upstreams were writing proper
> > autotool files and where following upstream autotools as they apparently
> > are doing wrt. other tools, this issues would not exist.
> 
> Or if autotools maintainers would stop changing the interface so 
> freaking often, this wouldn't be a problem either....
Apparently you don't have much clues about the autotools.

They did not change the "interface so often".

There has been one big interface change: It occurred between
autoconf-2.13 and autoconf-2.50 - Many years ago.

All other changes since then had been minor. In the same time, gcc has
changed incompatibly many more times, not worth mentioning g++/libstdc++
or even c++ standards having changed.

Do you remember the gcc-4.3.0 recompilation campaign in Fedora some
months ago? If people had adjusted their autotool's source files with
the same engagement and submitted their changes upstream, for years ...
this issue would not exist ....

Ralf