Re: libtool pre-1.5b tests fail on 9 debian arches

[Earnie Boyd]

Oh, to the ode of creating new worms...

Robert Millan wrote:
> On Sat, Sep 27, 2003 at 07:26:20PM +0100, Scott James Remnant wrote:
>
> > Updating to any later version of Libtool is the same amount of work,
> > whether it be the Debian-patched version or not.  Most of the time, when
> > build failures occur, the package upstream is using either an insanely
> > out of date version anyway and needs updating whatever the case.
>
>
> That implies asking upstream to update their libtool using upstream libtool
> in first place, then replacing it with debian's libtool. Asides from the
> time-consuming effort this represents, the following are examples of problems
> that may (and usualy do) occur:
>
>  - libtool.m4 is in a non-standard location or even with a different name;
>    go search for it.
>  - aclocal.m4 won't regenerate with your version of aclocal, and the version
>    upstream used is not present in Debian (e.g: 1.7.6)
>  - configure won't regenerate with your version of autoconf, and the version
>    upstream used is not present in Debian (e.g: 2.53)
>
> Add here the fact that upstream is not responsive, and you get a whole can of
> worms. And this is only _one_ package, porters have to port hundreds of them.
>
> Of course, this is only for the situation when upstream updates their upstream
> libtool for you. When you have to update between different versions of libtool,
> you'll hit incompatibility errors (missing --tag option, anyone?).

Uhm, if you're testing a new version of libtool against all packages, 
then what you're doing is pointing out what needs changed to support the 
new version of libtool.

Given that the end user of the source does not have to have any of 
autotools installed (a GNU Standard requirement), the end user just need 
to execute ``configure'' for the given package.  If configure worked 
previously, then it should work now given a new verions of libtool is 
installed.  If a configure requires an autotools package be installed 
then the package isn't following the standard.  Standards were created 
for the purpose of making the process the same and thus everyone knows 
how to do it standardly.  If the package isn't owned by FSF, then so be 
it.  If the package is owned by FSF, then it needs to be forced to 
follow the standard.


> > The reason porters tell maintainers to use the Debian libtool package
> > and not the upstream version is simple... They've generally grabbed me
> > on IRC and we've gone through the build logs, and in some cases our
> > libtool package has been patched and uploaded first.
>
>
> Agreed. When a broken libtool has already been released, there's not much
> thing to do other than maintaining all these patches in Debian.

But if you're use of libtool isn't standard, then perhaps that is the 
problem.  To require all packages to support the new version of libtool 
at once is not standard.  To require the end user to have autoconf, 
automake, libtool or other maintainer configuration tools on their 
systems is not standard.  To require the packaged configure script to 
execute properly without these tools installed is standard, nothing else.

> > Getting appropriate patches submitted upstream is a difficult task, and
> > I'm not the only person who believes so, it is something I want to do
> > and have been trying to do, but it's proving hard work to get replies
> > half the time!
>
>
> We should start doing that, and I can help. Just requested copyright papers
> myself (I assume you've already done that).
>
> libtool maintainers: Would you consider giving either Scott or me (preferably
> both) with CVS access? That'd help a lot getting libtool in shape for all
> architectures without having to maintain such a "debian fork" of libtool.

And would that get it in shape for everyone else?  Why not submit 
patches that can be reviewed and discussed?

> > [...]
> > If that makes sense?  I wasn't intending to infer a new libtool project,
> > I was trying to indicate we wouldn't be able to use the original
> > upstream tar file in the package anymore.
>
>
> Yep, it makes sense now. (it's just the same I've been doing for Bochs)
>
>
> > I sent an e-mail over a month ago to open a discussion about this
> > problem, and it went unanswered.
>
>
> Let's reopen it.

Ok, it's open.  Now, have the patches been submitted for review?

Earnie.
--
http://www.mingw.org