httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: Signatures, and sealing wax, and..
Date Tue, 12 Aug 1997 14:32:14 GMT
On Tue, 12 Aug 1997, Rodent of Unusual Size wrote:

>     As I recall, for 1.2.0 we had some disparities when it came to the
>     content of binary kits.  I'd like to suggest the following, and open
>     the ball for discussion.  For 1.2.3, or whenever we next do a
>     release with binaries.  Wherever I say "should" below, I mean that
>     all the binaries must follow the same rules, whatever we decide them
>     to be.
>     1. Binaries should be built with the vanilla Configuration (i.e.,
>        no additional modules).  Possible exceptions: mod_status and
>        mod_info?

No.  I think they should be somewhere in the middle.  Thinks like
mod_auth_db* (whichever is appropriate) should be there, things like proxy
probably shouldn't.

>     2. httpd image should include platform name (maybe
>        "httpd.`helpers/GuessOS`"?)

Platform name is the way that the instructions have always said to do

>     3. Tar files should be available compressed with compress(1) *and*
>        gzip(1) (nothing new here).
>     4. Compressed tarchives should have accompanying .md5 *and* .asc
>        (PGP) signature files available.  (Yes, Ben, I know it's not as
>        good as signing the uncompressed tarchive, but it means people
>        can verify what they copy from the site w/o having to uncompress
>        it first.)

Erm... I don't think this is practical for the binary releases.

>     5. src/Configuration should use the platform's native cc(1) if it's
>        considered good, and *not* gcc - unless the native cc is suspect
>        or downright broken (HP-UX, can you hear me calling? ;-).

I don't see the point in this.

>     6. README files should all be virtually identical, describing the
>        above and whatever minimal exceptions there may be.
>     (Now, where's my flame-retardant suit?)
>     #ken    :-)}

View raw message