John Caruso wrote:
> Basically, AOLserver 4 is hostile to being built (or having its
> modules built) in anything other than its final installation
> directory.
Frankly, I'm not sure what you're talking about.
I explained one facet of it in great detail in my original posting--I'm not sure what I can add to that part of it. If you read the comments in the spec file snippet I provided I think you'll see what I'm talking about...but if not, let me know specifically which part isn't making sense.
The general issue is that many packages allow you to untar and make the package in a directory A, then "make install" into a directory B--but configured such that the resulting package will actually run in directory C (i.e. config files reference directory C, default file locations are set to directory C, library search paths reference directory C, and so on). This is extremely common in the open source world...in fact it's practically the standard for how to set up a publicly-distributed package.
For example, when you configure OpenSSL you specify --openssldir = /the/final/location/of/openssl, but when you install OpenSSL you can also specify an INSTALL_PREFIX which will be prepended to /the/final/location/of/openssl during the installation phase. Or for BIND 9 you specify the various runtime paths during the configure phase with options like --sysconfdir, --libdir, etc, but when doing the "make install" you can specify a DESTDIR which will be prepended to each of those configured paths during the installation step. Or with Apache, you do a "configure --prefix=/final/destination", but install using "make install root=/prepended/directory". Etc, etc, etc.
But AOLserver 4 doesn't let you do this, and in fact makes it very difficult to achieve at all (much more so that it was under AOLserver 3.4.2, as I showed in my posting).
One obvious place where this ability is useful is when you're building software that you want to run under a chroot jail. Having things like INSTALL_PREFIX or DESTDIR or root= available to you allows you to build the software using the correct paths for the chroot jail, but still install the software into the chroot jail rather than into the corresponding directories outside the jail (which could be a real problem if you've got one version of the software in the "real" location, but want to put another more restricted version of the same software into the same location within the chroot jail).
But the example that matters most to me is building an RPM, which is what I'm dealing with. Building an RPM typically involves these steps:
1) The software is built by the RPM spec file (the initial "make" step) in a build directory, e.g. /usr/src/redhat/BUILD/aolserver4
2) The software is then "make install"ed into a buildroot directory (e.g. /var/tmp/aolserver4-buildroot), under which the package is installed with complete file paths--so for example, if the intended install destination of the package is actually /usr/local/aolserver4, the RPM spec file would install the files into /var/tmp/aolserver4-buildroot/usr/local/aolserver4. This is good because you don't want to have to have RPM building packages in their final locations, since there may already be a package occupying that location. Also, if you're not building the RPM as root, you may not have write access to the final destination directory--so without the use of a buildroot you wouldn't be able to build the package at all.
3) When packaging the files, RPM strips off the buildroot directory...so when the RPM I'm using as an example here is installed, the files would actually show up under /usr/local/aolserver4.
When I say that AOLserver 4 wants to be built into a directory that's also its final destination directory, I basically mean that in step 2, there's no way to say "Install into /var/tmp/aolserver4-buildroot/usr/local/aolserver4, but configured so that you'll actually run out of /usr/local/aolserver4". For OpenSSL or BIND (and almost every other major open source software package I've ever worked with) this is extremely easy...but for AOLserver 4, it's a major headache. And it gets far trickier when you add modules into the mix, since they typically expect to be built against an already-installed AOLserver instance which is living in its final location (somewhat so in AOLserver 3.x, but far more so in AOLserver 4, because of the new library requirements). It took some serious surgery to be able to build AOLserver 4 + all desired modules in one location (the build directory), then install them into a second location (the buildroot), but configured such that they'd actually run in a third location (the actual destination directory).
This isn't a problem if you plan to compile/install AOLserver on a single system. But if you're building it for distribution to many machines via a mechanism like RPM, it's an issue.
The info above about RPM is explained in more detail here, BTW:
http://www.rpm.org/max-rpm/ch-rpm-anywhere.html
Hey, you asked. :-)
- 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.
