[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: Scott James Remnant
Subject: Re: libtool pre-1.5b tests fail on 9 debian arches
Date: Sat, 27 Sep 2003 04:30:15 +0100

(Removed debian lists from Cc, I don't see how this is relevant to the

On Sat, 2003-09-27 at 06:06, Robert Millan wrote:

> On Sat, Sep 27, 2003 at 02:36:13AM +0100, Scott James Remnant wrote:
> > Use the Debian libtool package, not only do I currently track CVS rather
> > than use the pure 1.5 release, there are additional Debian patches added
> > to make it work on some of the architectures.
> It's not the Debian libtool package which is (generaly) used by upstream
> maintainers to update their libtools. My concern is with upstream packages
> using upstream libtool, hence the Debian package is not relevant.
Which therefore makes me wonder why you Cc'd the various Debian ports
lists.  We've had an unofficial policy for some time now that porters
will request/require package maintainers to use the Debian libtool
package if things break.

We're all VERY well aware that upstream libtool isn't portable across
all Debian architectures, it doesn't work on arm at all -- and until
recently didn't work on mips, mipsel or m68k either!

This is precisely why Debian's libtool package contains so many
additional patches, so when things do break we can just tell the
maintainers to update the package with the libtool installed on their

> > Getting these patches accepted upstream is tricky though, I've sent some
> > bug fixes through.  A few days ago I decided to have a go getting some
> > of the portability patches (some of which are large) accepted, I mailed
> > the smallest (yet one of the more far-reaching ones) to -patches;
> > haven't had any follow-up yet though.
> My patch sending policy involves pinging them after a week of not responding,
> then periodicaly pinging them at increased rate. It's quite effective.
It can be, but very often patches or mails I've sent are simply
ignored.  I'm almost positive the pass_all patch will be rejected, if
it's ever even considered.  And yet without that patch, Linux ARM and
libtool won't be friends.

> Could you try merging all the other patches, so that we can reliably test
> libtool on all of Debian's arches?
Only once I've had some degree of success in getting some of the trivial
patches applied will I actually worry about untangling the various
changes and making them into patches.  It's a non-trivial amount of work
for each patch, and there are more than a dozen now -- a few of them
quite large.

Not to mention the various copyright problems that GNU will care about
... a fair chunk is my copyright, but some of the patches which have
fixed Debian problems have come from others -- quite a few off the
-patches list which upstream also ignored, and yet they fixed problems.

There's also the problem that Debian may not be able to continue
distributing the upstream libtool tar file at all, because it contains
non-free material (the GNU FDL licensed documentation) -- at which point
I'll simply fork Debian libtool and maintain it by merging every so
often with GNU libtool.

If you're interested whether upstream's libtool releases are portable
between Linux architectures, you've already done that test and seen that
they are not.

I don't see the distinction between testing with Debian's libtool
package, or the upstream libtool with Debian's patches applied?

Debian's package "works" (except for the ia64 test problems, which I
strongly suspect are problems in the test code not libtool) which is why
when things break we tell maintainers to use our package instead
whatever random version upstream found on their hard drive.

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

reply via email to

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