Forum OpenACS Q&A: Response to Enhancing the Installation Process: Automation.
Well, Ben, Don: whether we support upgrading or not is really immaterial from an RPM standpoint -- because there is no such thing as an RPM upgrade, in actuality.
While 'rpm -U' and kin give the impression of an upgrade, it really isn't an upgrade unless the RPM has scriptlets to make it one -- other than some fancy dependency/file/etc stuff that goes on in RPM's database, that is, but we don't need to go into that for this discussion 😊. Without the scripts it's just an 'install new version/wipe old version' ritual that is very well automated.
What does 'rpm -U' do that 'rpm -i' doesn't? The 'rpm -i' simply won't overwrite what's already there -- 'rpm -U' installs the new RPM on top of the old RPM's contents -- overwriting files as it is instructed. Then, 'rpm -U' performs an 'rpm -e' of the old package -- skipping, of course, overwritten files. A package contains more than just files -- there is version info, dependency info, membership info, and other info that is critical to proper installation/upgrading that RPM just make do the Right Thing (most of the time, that is). Berkeley DB sits at the backend of RPM's database.
Now, here's the tickler -- most RPM users are accustomed to simply typing 'rpm -Uvh list-of-package-names' and letting RPM sort out the fallout -- beyond that, most RedHat users upgrade by booting the new OS disk and selecting 'Upgrade' -- and anaconda (RedHat's installer) will then dutifully do an 'rpm -U' for each package that needs it -- with no user interaction possible other than selecting which packages to upgrade. No, the package itself can't deselect itself, unfortunately.
A 'holding cell' prevents user sites from being overwritten, while also providing a local repository of the latest OpenACS code. And, if our goal of RedHat shipping OpenACS is realized, we _will_ have to confront this demon sooner or later. There are no special cases allowed by anaconda (except on the much less valuable (for our purposes) 'PowerTools' CD). Although it is going to be a neat trick to get RedHat to put AOLserver on the main CD set (it's up the three CD's, now).
If planned for and implemented properly, sure, it's possible to put a DB instance on the holding cell, for the impressionable folks. aD is currently running arsdgita.com on a CVS checkout, right? If they can do a cvs update on a live tree and get results, then we should be able to do similar. HOWEVER, datamodel changes are much trickier -- but, maybe the policy should be that the holding cell installation's datamodel is going to be blown away at every upgrade? I _know_ the datamodel is going to be rough to update in-place on PostgreSQL.
As a 'booster toolkit', it is, IMHO, essential to have live sites uninterrupted during upgrades -- which are unavoidable on a RedHat system run by typical RedHat admins -- thus, my suggestion of a holding cell -- /usr/share/openacs-version is the cell, upgradable at will. The install scripts simply make copies from the repository as needed for fresh installs -- and customized sites aren't touched.
Although migration and update 'guidescripts' would be nice, to assist with determining just what needs to be updated on any particular ACS install.
But, the short of it is an RPM is not practically made 'install-only' -- unless you want our RPM's abort of an upgrade to abort someone's OS upgrade (a real quick way to get kicked off the RedHat CD's....). RPM's are pretty brain-dead -- but that is one of the reasons RPM-based systems, when the packager(s) plan and build dependency trees properly, install and upgrade so robustly: there is very little happening, which means that there is very little that can go wrong.
----
Tangent:
This HTML-wizard package manager sounds intriguing.....
----
Don, your help is greatly coveted. I have already shaken the Great Bridge tree, but no apples have fallen as yet. Gravity must be weaker in Norfolk. Actually, I was contacted by them regarding installation issues, and I threw the upgrade issue out with the reply.
Since we can't practically prevent a user from attempting an upgrade due to RPM's design, we will have to work around it -- the holding cell idea is one way to provide an upgrade 'target' that is safely overwritable -- I'm sure there are others.
Comments?
