Forum OpenACS Development: Responses to RPM stuff.

Anyway, let me address the thoughts brought up.

First, it's good to be able to be back. I am revamping our Intranet site to OACS 4, so work once again realigns with hobby, allowing me the time to do this again. My management here is very excited about workflow in particular, and the ticket tracker as a major secondary. I will be writing packages for several radio-station type applications, including an interface from our automation system to the web page (for a scrolling program guide on our Internet site as required by CARP). There are a few others -- we currently have a major workflow-esque process during our yearly fundraiser, and many things in a radio station's operation can be workflowed right nicely (such as the process of putting a program on the air -- there is scheduling, billing, promo production, intro/lockout production, notification of programmer, etc). So these are exciting times. I have a day or two a week for most of the summer budgeted for it, so I'm looking forward to digging in.

Next, the RPM system allows all sorts of dependency information to be codified. Much of this is completely automatic (such as the AOLserver dependency upon libxml2, which most modern Linux dists include (RH 7.x for instance)). Others, like preventing an OpenACS RPM upgrade must be hardcoded (to do this, a Conflicts: OpenACS < current-version tag would work). And PG's upgrade is very broken. But an AOLserver upgrade shoud be mostly painless, unless AS 4 is radically different from AS 3 (which it is shaping up to be not-quite-radically different.....I'm tracking AS 4 CVS).

Subpackages could easily handle many of these concerns -- in fact, I would _want_ several subpackages in order to cleanly implement the dependencies. As the RPM packager has fine-grained control over the package's dependencies (and provides), the only hard part about this is making a sane subpackaging scheme.

Splitting ACS Packages out into separate RPM's can be done rather easily, and would likely be the best way to handle such dependencies. For instance, I wasn't aware of workflow's dependency upon Graphviz, or the photo stuff's on IM. Those sort of dependencies need to be either applied to the whole dependent package or to the dependent subpackage.

And RPM-based distribution users are used to resolving dependencies -- likewise, if OACS ever made it into a shipping distribution as an install item, accurate package depends are going to be mandatory -- and the various installers (such as RedHat's anaconda) are very much aware of package installation order and dependencies, and automatically handle such.

Although a depends on ImagMagick could be problematic for somd server installations -- but Red Hat is now forcing X on even server installs. Well, the Xlib stuff at least. An X-less server running current RedHat is difficult to obtain at the least.

Now, on to the APM versus RPM issue for ACS packages. I can see the merits of both mechanisms. ACS knows how to handle package installation -- although I had to force some packages to install here due to some odd dependencies on packages that were already installed... But RPM knows how to handle external-to-the-ACS-core dependencies in a sane manner. And, if APM knows how to handle a package 'dropped into' the installed dirs, as Don implies, then maybe this could be a hand-off, allowing RPM to handle dependencies and APM to handle bootstrapping. The core RPM would then Provide: each of the core packages, and the sub-RPM's would have a Requires: on those core packages needed.

A script could be written to parse the APM dependency info into RPM Requires and Provides info during RPM build from the spec file.

But if we're going to do the RPM thing, proper dependency information is a must for sane operation of the systems RPM database.

Next, the question of differing goals comes up. Michael has an excellent point here. I would look towards the Great Bridge (RIP) installer, which, IIRC, is still available on gborg.postgresql.org, as a model installation system that uses RPMs as the backend package. The Loki installer (source still available from CodeWeavers at least) is a nice, open source graphical installer -- I don't know about Win32 and MacOS, though.

RPM is designed to assist in installation, not replace a good GUI installer. An AOLserver-backed web-based installer might be the right direction, with the service name and all the AOLserver options available from there.

RPM install automation != a GUI installer's automation. RPM cannnot have an interactive install (unlike Debian). Install first, then run a script or GUI for configuration. If you want a good 'vertical' installer, then write such an animal with RPM bindings so that you can install the packages as RPM's, with all of RPM's nice dependency tracking, but with the GUI layered above, allowing configuration immediately after the RPM's are installed. Python is one language that (thanks to anaconda) has excellent RPM/librpm bindings to allow direct installation and configuration. The Loki installer can be a shell archive (CodeWeaver's 'CrossOver Office' and 'CrossOver Plugin" are distributed this way) that the user simply executes, bringing up whatever window(s) is/are necessary. This is a wheel already invented.

The amount of automation would be determined by the answer to the question 'What is the minimum set of operating data that is absolutely required to be entered by the target sysadmin?' And I _do_ mean sysadmin -- a webserver installation is one not likely to be tackled by any but a sysadmin.