Forum OpenACS Development: RPM Caveats.

11: RPM Caveats. (response to 1)
Posted by Lamar Owen on
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.