Re: Removal of libtool1.4
Scripsit Anthony Towns <aj@azure.humbug.org.au>
> On Thu, Jan 15, 2004 at 05:54:01PM +0000, Henning Makholm wrote:
> > If the frequency of libtool1.4 use in the 'a' packages is
> > representative of the whole archive, I expect to find about
> > 540 source packages in total that have traces of libtool 1.4.
> So, does this actually matter?
Yet unknown. After starting the search it has come to my attention
that many of the packages found actually do use autoconf 2.5x, but
just haven't been updated since the new libtool was packaged (which
happened fairly recently).
So I'm going to repeat the scan for the 721 packages where signs of
libtool 1.4 were found, this time looking for autoconf2.13-generated
configure scripts.
Anybody got a good automatic way of checking whether a configure.in
will require nontrivial porting for use on 2.5x?
> The packages are still buildable, and presumably still patchable if
> we need to do a security update. What more do we want?
I like to think that our promise that main is closed with respect to
building tools implies, at least morally, that users can make trivial
changes to packages in main in the preferred form for modification
(say, configure.in) and recompile without needing any software outside
main to build it.
Therefore, I hold that if we remove libtool1.4, then it becomes a bug
if the internal configuration infrastructure in a package cannot be
rebuilt without having libtool1.4 installed. I'm not ready to argue
that it would be an RC bug, but I'm quite convinced it should be a bug
unless the configure.in needs more than a few very obvious changes to
port.
--
Henning Makholm "Manden med det store pindsvin er
kommet vel ombord i den grønne dobbeltdækker."
Reply to: