httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: 2.0.35 for Darwin was Re: where to describe criticalOS-specific requirements
Date Tue, 09 Apr 2002 14:07:33 GMT

> "rbb@apache.org" <rbb@apache.org> wrote:
>
> > On Tue, 9 Apr 2002, Justin Erenkrantz wrote:
> >
> >> On Mon, Apr 08, 2002 at 11:50:34PM -0700, Ryan Bloom wrote:
> >>> Guys, this is a SOURCE tarball.  We don't need to provide every possible
> >>> software combination for source tarballs.  If one of our users requires
> >>> a specific version of libtool, then they can install that version.  If
> >>> it is a binary install, then we have to use a specific version.
> >>>
> >>> If you try to do this for every version, we'll have hundreds of tarballs
> >>> for every release.
> >>
> >> The problem is that there is *no* version of libtool available
> >> that works out-of-the-box.  If we could tell people to just
> >> download libtool-1.4.2 and use that, that'd be fine.  But, we can't
> >> do that since no version of libtool released by GNU works on OS X.
> >> So, I think we can be nice and provide a tarball that has a
> >> working libtool.
> >
> > That makes me like the idea of a special package even less.  If I can't
> > get a working copy from libtool, then I can't package it cleanly.  When we
> > first went to libtool, we called out this problem and said that we would
> > be reliant on the libtool team to make things work.  Now we have to deal
> > with that.  The solution isn't to create a hacked version of libtool,
> > IMNSHO, it is to work with that team to make sure that they have stuff
> > that works.

+1

>
> Ryan, if you look into the archives, you'll see that I tried (several times)
> to submit patches to the LibTool team... And version is still 1.4.2...

Lets not give up. I would suggest we spend some time hashing out all the things we need to
get fixed, then work up a patch (or series of patches) to submit to the libtool dev team.
Clearly describe the problem being fixed and generally make the problem as easy to see and
understand as possible and keep the patch as small as possible (all the things we like to
see in patches from unknowns :-), and I am confident they will accept it (or reject it on
technical grounds).

Bill


Mime
View raw message