[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Earnie Boyd
Subject: Re: libtool pre-1.5b tests fail on 9 debian arches
Date: Sun, 28 Sep 2003 09:16:30 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]