(Removed debian lists from Cc, I don't see how this is relevant to the
porters)
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
system.
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.
Scott
------------------------------------------------------------------------
_______________________________________________
Libtool mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/libtool