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

Klee Dienes
2002-12-05T22:29:38Z

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