Since there's been discussion of the installation chapter of the admin guide (which looks great, BTW), I thought it would be good to bring up the issue of packaging AOLserver 4. To deploy AOLserver at Arena, we maintain an RPM that we use to package together AOLserver and all the modules we use with it (e.g. nsopenssl, tDOM, nsoracle, rlreturnz, et al). This is extremely useful since it makes it very easy to deploy (or roll back) updates in a controlled way.
With AOLserver versions through 3.4.2 it was fairly simple to compile and install AOLserver and these modules into a special RPM buildroot directory and package the whole thing from there, but with AOLserver 4 this is far, far more difficult. Basically, AOLserver 4 is hostile to being built (or having its modules built) in anything other than its final installation directory.
Here's an example. This is a portion of the %build section of our RPM spec file for AOLserver 3:
------ 8< -----------------------------------------------------
%build
echo "===== AOLserver make ====="
pushd %{AOLSOURCEDIR}
make
popdecho "===== rlreturnz make ====="
pushd %{RLRETURNZSOURCEDIR}
make NSHOME=../%{AOLSOURCEDIR}
popd
------ 8< -----------------------------------------------------As I said: fairly simple. But this is the analogous section with AOLserver 4 (I've left in some of my comments, since they explain the requirements that drive the differences):
------ 8< -----------------------------------------------------
# The RUNTIMELIBS variable is used to override LDRPATH and CCRPATH in the
# generated AOLserver Makefile(s). These variables are used solely to set
the
# library search paths at runtime; since we're building the entire package
# in a special non-installation location (i.e. the RPM buildroot), we have
to
# override the internally-generated -rpath settings (which reference the
paths
# specified during the building of the package and modules).
#
# The LDFLAGSMAKE variable is used to set LDFLAGS for making certain
modules.
#
%define RUNTIMELIBS "-Wl,-rpath,%{INSTALLDIR}/lib:%{TCLLIB}"
%define LDFLAGSMAKE "-L../%{AOLSOURCEDIR}/nsd
-L../%{AOLSOURCEDIR}/nsthread"# Note that we must configure with --prefix=`pwd` at this point;
otherwise,
# standard module builds will fail, since the generated Makefile.global
# references this path (in other words, it assumes that AOLserver is being
# installed BEFORE the modules are built, whereas we want to build
AOLserver
# and the modules first and then install them all together in the %install
# section). This --prefix setting is incorrect for the install, of
course,
# so we have to override it in the %install section by setting the
AOLSERVER
# variable in the "make install" line for AOLserver.
#
echo "===== AOLserver make ====="
pushd %{AOLSOURCEDIR}
./configure --with-tcl=%{TCLLIB} --enable-symbols --prefix=`pwd`
make LDRPATH=%{RUNTIMELIBS} CCRPATH=%{RUNTIMELIBS}
popdecho "===== rlreturnz make ====="
pushd %{RLRETURNZSOURCEDIR}
LDFLAGS=%{LDFLAGSMAKE} make NSHOME=../%{AOLSOURCEDIR}
LDRPATH=%{RUNTIMELIBS}
popd
------ 8< -----------------------------------------------------As you can see, this is far more complex than the AOLserver 3 steps (and there are other issues as well that I've left out, but these are illustrative of the problems). Getting this to work at all was a major chore; I had to go through the AOLserver 4 Makefiles and config files painstakingly to determine that I had to override LDRPATH and/or CCRPATH variables and override the LDFLAGS settings during the build step with various modules, to determine how to handle the NSHOME/AOLSERVER/INST variables during the building and installation steps (for which the settings must be different), and so on.
BTW, we've decoupled the Tcl RPM from the AOLserver RPM for AOLserver 4, and the TCLLIB variable points to the installation directory for the Tcl RPM; if we hadn't done that, this would be even messier.
In recent years packages have been becoming more friendly to package maintainers by allowing the package to be built in a separate directory from the actual installation directory, and it's too bad that AOLserver 4 isn't following this trend. It would be nice to see AOLserver 4 architected so that the building of AOLserver and its various modules could easily be decoupled from the choices for the final installation directories.
- John
-- AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
