[RFC] Update to current automake/autoconf/libtool versions.

[Klee Dienes]

Sure, but is it really a common situation where we are neither able to 
revert to a previous released version of libtool, or get a release of 
the upstream tools made with the needed fix in a timely fashion?

[ Here I wake up from my optimistic reverie and proceed to answer my 
own rhetorical question: ]

The answer to this, of course, is "yes," and I agree that poor 
backwards compatibility from autoconf-2.13 to autoconf-2.50 is the real 
source of the problem here.  My point is that the current solution 
doesn't seem to be addressing the real problem --- we have essentially 
created our own forked versions of all of the autotools, with no 
visible plans to re-merge to the FSF version, and no intent to maintain 
the forked version on our own.

I'm not arguing that it will never be necessary to fork our own version 
of autotools in the case of a short-term emergency (well actually, I 
might argue that, but I'm not arguing it here).  I'm just arguing that 
a forked version of binutils with no clear upstream referent is a 
particularly bad state of affairs:

	-rw-r--r--   1 77       1002       259210 Feb 27  2000 
autoconf-000227.tar.bz2
	-rw-r--r--   1 77       1002       292827 Feb 27  2000 
automake-000227.tar.bz2
	-rw-r--r--   1 77       1002       519132 Feb 27  2000 
gettext-000227.tar.bz2
	-rw-r--r--   1 77       1002       370603 Feb 27  2000 
libtool-000227.tar.bz2


On Thursday, December 5, 2002, at 03:24 PM, Ian Lance Taylor wrote:

> Klee Dienes <klee@apple.com> writes:
>
>> As long as the versions of the tools are specified by a version string
>> referencing an official version in README-maintainer-mode, and not by
>> "whatever version is on sourceware.cygnus.com", I'm happy.
>
> That works until there is a bug which is a problem for the binutils
> but there is not yet a new release.
>
> It's not a theoretical point.  That's the reason we started using
> versions stored on sources.redhat.com in the first place.
>
> Ian