[A quoted reply system would be nice....]
[First, thanks for taking the time to respond!]
<blockquote>1. Installing direct to a /web partition where the disk space and >file system is correct size and type is awkward.
</blockquote>
No, it's not 'awkward' -- it's against the Linux Filesystem Hierarchy Standard version 2.1 (available at pathname.com). For RPM's to be shippable by RedHat, they have to be FHS-2.1 compliant. /web is far from compliant.
<blockquote> 3. Upgrading TCL scripts, SQL scripts and in-production user > introduced customizations is well... well hard?
</blockquote>
Impossible, not hard. If not impossible, totally impractical. And unwarranted -- someone might actually _want_ the old behavior...
<blockquote> First; nsd, the java mail programs, and Postgres can be gathered >up as RPMs.
</blockquote>
PostgreSQL RPMs already are done. Need information ofn the preferred JRE to use for nsjava RPM's. AOLserver will have its own RPMset -- including a separate postgres-driver subpackage.
<blockquote> So the RPM or tarball or whatever of OpenACS has these parts:
</blockquote>
<blockquote> 1. A front end script.
</blockquote>
<blockquote> 2. A dumpfile or a complete database.
</blockquote>
Can't go into the standard PostgreSQL database location, unless you want to anger existing PostgreSQL users by overwriting their data. So a secondary location will have to be chosen -- and the existing PostgreSQL RPM startup scripts don't work well with that, so a separate script would have to be built... Doable, but not pretty. But, the binary data tree for each architecture possibly would be different, due to endian issues.....
<blockquote> 3. Dependency stuff for Postgresql RPMs etc.
</blockquote>
RPM handles nearly all of the dependencies in a fully automated fashion -- you don't have to specify most of them.
the whole idea of 'OpenACS in a database' is already done for the most part -- it's called CVS. Storing the whole OpenACS inside a PostgreSQL database is likely to run up against the tuple size limit.
<blockquote> 6. We need to pick a good way to label each file with the >dependencies on specific versions of TCL, Postgresql,
</blockquote>
This could be useful -- but not just for RPM's. Of course, it makes it horrifically complicated for the developers, who have to do the labeling of version information. Is it not maybe better to say 'to upgrade to version x.yy of OpenACS requires PostgreSQL zz.aa.bb, AOLserver cc.dd.ee, and the driver version ff.gg.hh? There are many changes between versions that are not incremental -- 3.x to 4.x, for example, will require changes to nearly every Tcl file in every module.
As to package dependencies as I said above, RPM handles that very well and very simply -- and almost entirely automatedly. Very few dependencies have to be hand-entered -- and even those are on a package-wide basis, not file-by-file.
Interesting thoughts, though.
