It's been some time since I've been involved with the ACS/Pg ...
sorry, OpenACS project, but I'm getting back to it now that a few
things have stabilized here.
First, I can make RPM's for a complete initial server stack that
work with my existing PostgreSQL RPMset. This is easy --
particularly the way OpenACS is already packaged -- it's basically
just an AOLserver installation (separate RPM), the drivers (separate
RPMS), config files (whose defaults can be massaged easily enough),
and the /web tree.
However, an RPM installation is no panacea. There are a number of
things that must be addressed by a prospective OACS RPM set:
1.) How much do we want to automate in the configuration of the
install? Install isn't hard anyway -- particularly with the web
bootstrap. How much _CAN_ be automated? (Think this through very
carefully) Then remember that RPMs are not supposed to write to
stdout or read from stdin during installation....
2.) How much do we want to default? After all, one of the
biggest steps in the install is figuring out the service name.
IMHO, having the service name hardcoded as a directory name isn't
the best solution -- what is a reasonable default?
3.) Remember that RPM is a _package_ system and as such is
designed for installation, uninstallation, and upgrading of
packages. Which brings us to:
4.) How much upgrade functionality do we want? An RPM upgrade is
an 'install new version then erase previous version' process, with
lots of script munging going on that is not obvious. Of particular
note is the obfuscatory way in which the various installation
scriptlets run, and their order -- particularly if trigger scripts
are involved. The PostgreSQL RPMs have serious issues with upgrades
that I have over many months tried to work with, and have had
difficulty getting to work right. To the point that I'm about to
change fundamental aspects of the package in order to get something
a little less broken.
But RPMs need thorough thought before blindly implementing them.
And a review of the existing 3.x RPMs is most definitely in order --
if they have reasonable defaults, the principle of least surprise
holds. But likewise, is upgrading from them even supportable?
And /web has got to go in the RPM context... /var/spool/openacs,
perhaps. Or some other FHS area. But /web is positively begging
for trouble on most systems.
All comments welcome, particularly from the one who put together the
3.2.5 RPMset.
