FESCo Proposal for blocking older version of autoconf & automake

[Ralf Corsepius]

On Mon, 2008-05-05 at 23:34 +0100, Richard W.M. Jones wrote:
> On Mon, May 05, 2008 at 06:10:50PM +0200, Ralf Corsepius wrote:
> > How do you call projects who stick with antiquated tools and ignore many
> > years of development? I call them poorly maintained.
> 
> 'Mature'?
That would be OK, if these packages "just work", i.e. not force users to
using their 

>   Actually while I personally tend to use whatever version of
> autoconf is installed for my own stuff,
Hear, hear!

That's the way the autotools are supposed to be used by _developers_.

It may surprise some folks, but it really works without major problems
when packages are using the autotools properly (1000s of packages are
doing so). One occasionally trips a minor issue when one of the
autotools is being upgraded, but nothing actually serious.

It really is simple as: You once need to take the plunge, then things
are really simple.

>  I have found a couple of
> upstream projects that use autoconf 2.13 and are opposed to upgrading,
> so that is going to be a problem. 
Yes, you will always be able to find projects sticking to antiquated
tools and refusing to accept that they are doing something stupid.

So far, most packages I have come across sticking with autoconf-2.13 are
simply relying on exploiting bugs and undocumented features from
autoconf-2.13 (In autoconf-terms: bugwise-compatible configure scripts).

Several larger packages suffered from such issues, but if maintainers
are willing, these issues can be overcome. Even GCC and almost
everything in src/ (aka. ueberbaum, binutils, newlib, gdb, gdb etc.) has
managed to do so. 

Another class of issues is people mixing up "minimum required versions"
with "version to use". This causes some developers to use autoconf-2.13,
even though it would be suitable for autoconf > 2.13 (Popular in
Debian).

Ralf