(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 -- 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
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
