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

[Robert Millan]

On Sat, Sep 27, 2003 at 04:30:15AM +0100, Scott James Remnant wrote:
> On Sat, 2003-09-27 at 06:06, Robert Millan wrote:
> > 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.

Which is an oddly insane policy. Updating libtool is a non-trivial task most
of the times and not a simple "libtoolize" run as you could pretend, I can
give you examples if you like.

I'm asking myself why some Debian porters prefer spending hours mass-filing
"update libtool" bugs everytime libtool breaks for them, instead of fixing
libtool properly in upstream.

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

Great. So if libtool is broken in upstream and breaks for all the non-Debian
world we just don't care?

Isn't this a violation of the Debian Social Contract?

        "We will feed back bug-fixes, improvements, user requests, etc. to the
        \"upstream\" authors of software included in our system."

(http://www.debian.org/social_contract)
 
> 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.
> 
> [...]
> 
> 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.

I'm aware of all this. And I can help you if you like.

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

So you want to fork a project because it contains non-free components? I've
been maintaining Bochs and Plex86 in Debian for quite some time now. They
have _always_ come with the non-free VGA BIOS, and I just removed it with
every update. Never considered forking for such a reason.

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

Nor do I. But you can't ask all developers of packages using libtool to start
using either of these instead of the official libtool releases.

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