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

[Scott James Remnant]

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

> On Sat, Sep 27, 2003 at 07:26:20PM +0100, Scott James Remnant wrote:
> > 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.
> 
> That implies asking upstream to update their libtool using upstream libtool
> in first place, then replacing it with debian's libtool.
> 
We've tended to leave that decision up to individual maintainers so far.

> Asides from the
> time-consuming effort this represents, the following are examples of problems
> that may (and usualy do) occur:
> 
>  - libtool.m4 is in a non-standard location or even with a different name;
>    go search for it.
>  - aclocal.m4 won't regenerate with your version of aclocal, and the version
>    upstream used is not present in Debian (e.g: 1.7.6)
>  - configure won't regenerate with your version of autoconf, and the version
>    upstream used is not present in Debian (e.g: 2.53)
> 
Or an even better one, just from build failures in the last few days ...
upstream placing the contents of libtool.m4 in acinclude.m4, so even
after aclocal runs the old version is still used.

One thing about maintaining a GNU auto tools package, you certainly see
some brain dead practises by other upstream developers.  Do these guys
not read the manuals? :)

> > 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!
> 
> We should start doing that, and I can help. Just requested copyright papers
> myself (I assume you've already done that).
> 
> libtool maintainers: Would you consider giving either Scott or me (preferably
> both) with CVS access? That'd help a lot getting libtool in shape for all
> architectures without having to maintain such a "debian fork" of libtool.
> 
I brought it up about six months ago (about the same time I sorted
through all the patches), I'm quite willing to undergo the paper signing
-- <consider this a request>.

> > 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.
> 
> Yep, it makes sense now. (it's just the same I've been doing for Bochs)
> 
> > I sent an e-mail over a month ago to open a discussion about this
> > problem, and it went unanswered.
> 
> Let's reopen it.
> 
Gary, Peter, Bob?  Probably the best compromise all round would be to
add something like this to libtool.texi below the current permission
statements:

        Provided this document contains no Invariant Sections,
        it may instead, at your option. be copied, distributed
        and/or modified under the same terms of the Software it
        accompanies.

or if you'd prefer:

        Provided this document contains no Invariant Sections,
        it may instead, at your option. be copied, distributed
        and/or modified under the terms of the GNU General
        Public License as published by the Free Software
        Foundation; either version 2 of the License, or
        (at your option) any later version.

That way you'd still be distributing the documentation under the GNU FDL
according to the GNU standards, with the dual-licence of the GPL which
would satisfy Debian's free-ness requirements.

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