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 #