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

[Scott James Remnant]

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

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

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.

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!

When the 1.5 package was prepared, and indeed why it took so long, I
placed it in a Subversion repository and spent some time splitting out
the individual changes and applying them to 1.5 as discreet commits.

Since that time, I've been sending some of the "fringe" ones upstream to
gauge how easy it's going to be to get the rest applied.

It'd be the work of an afternoon to mail the rest to -patches, if
upstream are happy to work though them.

> > 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.
> 
Uh, sorry, the exact meaning I was intending got lost in that
paragraph...

The current Debian package consists of 1) the upstream libtool tar file
and 2) the patches.  It's actually generated by exporting the "Debian
libtool" Subversion tree and running debuild with the upstream tar file
in the right place.

That way we end up with a "pristine upstream source", with all the
Debian modifications in the .diff.gz alongside it.

Because the documentation is non-free, and this will be most-likely
enforced the day after sarge is released, it *cannot* be distributed by
Debian.  This means we won't be able to distribute the upstream tar file
because it contains non-free material.  Therefore the Debian package
would change to consisting of a single "Debian libtool" tar file, which
would be the export from the Subversion tree.

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.


I sent an e-mail over a month ago to open a discussion about this
problem, and it went unanswered.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?

signature.asc
Description: This is a digitally signed message part