httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [pre-release] 2.0.55 *candidate* available for testing
Date Mon, 10 Oct 2005 20:04:27 GMT
Luc Pardon wrote:
>>Oden Eriksson wrote:
>>
>>>And some investigations told me it requires apr 0.9.7, maybe the autotools 
>>>stuff should check for this or be documented?
>>
>>Yup - apr 0.9.7 is part of the bundle.  We can spell this out in the
>>announce, certainly, and on the downloads page README - would that
>>suffice?
> 
>   There seems to be a bug in the httpd.spec file.
> 
>   It says: 
>     Requires: apr >= 0.9.5, apr-util 0.9.5
>   and the devel packages (on the httpd package specs) have no version
> number:
>     BuildPrereq: apr-devel, apr-util-devel
>   
>   Also, the changelog section in the spec file does not show the upping
> to 2.0.55. The last documented chenge is for 2.0.53. And it says:
> "changed build to use external apr and apr-util".
> 
>   This confuses me, since apr seems to be present in the 2.0.53 and
> 2.0.55 tarballs ... 

APR was also present in the 2.0.54 tarball.

This was a snafu in the way the rpm change was presented, not in the
tarballs.  httpd-2.0's distribution tarball will always contain apr 0.9.

That doesn't mean httpd-2.2 (with apr 1.x) will do the same; that's yet
to be determined.

Coming back to rpm's for the moment; I do *not* mean to suggest that
this is the best solution for any specific platform or distribution
method, be it .rpm, .depot, .pkg, .msi, or any other facility.

The problem is that packaging is almost a 20/20 hindsite game.  There's
no way we should expect that all of these many platform specifics can
all be maintained pre-release.  That's why, in the Win32 .msi case,
there is a seperate httpd/httpd/win32-msi/trunk/ containing the win32
packaging flavor.  It doesn't get fixed for a specific release until
we know exactly what needed to be fixed :)

I'm concerned that the current .spec solution is wrong; it's very
platform specific (platform meaning deployment mechanics, in this
case, I'm not slamming non-unix rpm implementations).  Perhaps we
rejigger the tree to

   httpd/
     package/
       roll-release/
       win32-msi/
       rpm/
       pkg/

Thoughts?

In the interim; is this a showstopper?  Do we generally do the right
thing (e.g. without changes, can we package up using the existing
rpm files?)  Obviously 2.0.54 was mispackaged as well, it's minimum
apr package dependency should have been 0.9.6 apr, not 0.9.5.

Bill




Mime
View raw message