On Tue, 2004-01-13 at 15:34, Adrian Bunk wrote: > On Tue, Jan 13, 2004 at 12:03:16AM +0000, Scott James Remnant wrote: > > > III: Finally, what's wrong with it? > >... > > And the silly thing is, it's not actually that *hard* to update lagging > > software to use Autoconf 2.5x, the autoupdate tool that comes with it > > does a reasonable enough job to get you most of the way there. It would > > be far better, given I and III, for those few remaining pieces of > > software currently using Libtool 1.4 (and Autoconf 2.13) to update. > > > > Talk over, let the wars begin! > > The reasons you mentioned against keeping libtool1.4 are abbreviated: > It's no longer maintained upstream, partly buggy, and rarely used. > > But it seems there is no big harm if libtool1.4 stays in Debian (e.g. it > doesn't include a security hole). > The problem is the diminishing architecture support. Libtool has to specifically support an architecture before it can build shared libraries for it, it doesn't have any fallback feature tests (because it's kinda hard to test for certain things). For example, Libtool 1.4 (currently) lacks support for GNU/kNetBSD, GNU/kFreeBSD and GNU/Hurd. It's only due to my maintenance that it's able to build shared libraries on arm-linux and m68k-linux. > I've checked cyrus-sasl. In this package it's perhaps not impossible, > but some work that requires autoconf knowledge to fix it to work with > autoconf 2.5x . > > Please don't remove libtool1.4 until no package in unstable has a build > dependency on libtool1.4 (or all remaining packages have tested patches > in the BTS). > Part of my theoretical removal plan would be to help update the depending packages to the later stuff before it happened. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist?
Attachment:
signature.asc
Description: This is a digitally signed message part