rse 98/06/09 08:50:07
Modified: . STATUS Log: First cut to remember the binary tarball issue. I'll add pro and cons to both variants tomorrow for both better decision. Revision Changes Path 1.420 +36 -0 apache-1.3/STATUS Index: STATUS =================================================================== RCS file: /export/home/cvs/apache-1.3/STATUS,v retrieving revision 1.419 retrieving revision 1.420 diff -u -r1.419 -r1.420 --- STATUS 1998/06/09 14:23:50 1.419 +++ STATUS 1998/06/09 15:50:03 1.420 @@ -144,6 +144,42 @@ Open issues: + * How should an Apache binary release tarball look? + + 1. The "old" way where it is just a source release tarball + plus a pre-compiled src/httpd-<gnutriple>. It is created + via the apache-devsite/binbuild.sh script which + - creates the build tree + - creates the src/Configuration file with standard modules + - runs "make" + - renames src/httpd to src/httpd-<gnutriple> + - runs "make clean" + - packs the build tree stuff together + Already known discussion points: + - should src/httpd be renamed or now because a lot + of PRs say they cannot find the httpd :-( + Pros: <gets filled tomorrow> + Cons: <gets filled tomorrow> + Status: Ralf -0 + + 2. The way other projects release binary tarballs, i.e. + a package containing the installed (binary) files. + It can be created by a script which + - creates the build tree + - runs "./configure --prefix=/usr/local/apache \ + --enable-shared=remain \ + --disable-module=auth_db \ + --enable-suexec ..." + - runs "make install root=apache-root" + - packs the stuff together from ./apache-root only!! + Already known discussion points: + - should there be a prefix usr/local/apache in + the tarball or not because some people think + its useful while others dislike it a lot. + Pros: <gets filled tomorrow> + Cons: <gets filled tomorrow> + Status: Ralf +1, Martin +1 + * Redefine APACHE_RELEASE. Add another 'bit' to signify whether it's a beta or final release. Maybe 'MMNNFFRBB' which means: MM: Major release #