Re: Removal of libtool1.4
Scripsit Scott James Remnant <scott@netsplit.com>
> On Sun, 2004-01-18 at 23:33, Henning Makholm wrote:
> > Scripsit Scott James Remnant <scott@netsplit.com>
> > > Run autoupdate and see if it explodes?
> > Possibly. Is it easy to notice the explosion mechanically?
> Probably checking whether the configure script has changed, or whether
> autoconf works, is good enough for an automated procedure.
No, see below, where I got bombed in a much later state of the process:
> > When I tried to rerun aclocal & autoconf (not libtoolize) for a package
> > on a system that had the wrong version of /usr/share/aclocal/libtool.m4
> > installed, what I got was an error that did not manifest until *build*
> > time. Not an error from autoconf; not an error from the generated
> > configure script. Only when the build process reached 'make all' did
> > things begin to go visibly wrong.
> Yeah, libtool can't tell it was made with the wrong version of
> libtool.m4 -- this is an old bug, and is in fact what I'm working on
> right now (for 1.6).
But even if it manages to tell that something is wrong, it still means
that in order to rebuild 1.4-based packages from source (aclocal.m4 is
not source, it is autogenerated), you. Need. Libtool. 1.4.
> > As described above, not having the correct libtool available means
> > that one cannot regenerate the *configure* script, and there are all
> > sorts of reaons to want to do that, even as a Debian maintainer.
> What you cannot do is update aclocal.m4 using the 'aclocal' tool, and
> quite frankly if you're still stuck on Autoconf 2.13 you should *NOT* be
> doing this anyway.
That makes us sound like a proprietary closed-source vendor. "No, yuou
should *NOT* be regenerating our software from source".
> Most of the stuff I found in /usr/share/aclocal seems to assume
> you're running Autoconf 2.5x these days.
If they do (and don't recover gracefully from being used by 2.13),
that's a bug in and of itself, I'd say.
> This is all being slowly phased out though, and instead we're moving
> towards gettextize/autopoint/libtoolize and their ilk placing their m4
> files in your application's source directory, so aclocal 1.8 can add
> m4_include() lines to aclocal.m4 rather than including them verbatim.
That is good. But I don't think it is a good reason to remove
libtool1.4 *before* the problem is actually solved.
> I'm half tempted to place the old 1.4 ltmain.sh and libtool.m4 in
> /usr/share/doc/libtool/historic (of the libtool package) so that they
> can be still gotten at.
Well, perhaps if you document it in big red blinking letters... But
still it'd be better to wait until the 139 possible problem packages
have been fixed.
--
Henning Makholm "Larry wants to replicate all the time ... ah, no,
all I meant was that he likes to have a bang everywhere."
Reply to: