libtool
[Top][All Lists]
Advanced

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

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


From: Robert Millan
Subject: Re: libtool pre-1.5b tests fail on 9 debian arches
Date: Sat, 27 Sep 2003 20:46:36 +0000
User-agent: Mutt/1.5.4i

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?).

> 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.

> 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.

> [...]
> 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.

-- 
Robert Millan

"[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work."

 -- J.R.R.T, Ainulindale (Silmarillion)




reply via email to

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