I think Ben's right. Additionally, I think the issue of PG upgradability is far more important to serious users of the database (not necessarily OpenACS) - pg_dump'ing when your dump is greater than 2GB is a royal pain, with the user needing to plot a strategy of dumping out tables in an order that doesn't break dependencies, etc. As long as pg_dumps occassionally need editing or massaging to reliably reload, this will always be true.
Plus, it's a bush-league "feature" of PG.
Same with the need to initdb so frequently, as I've mentioned to the developers in the past, the use of SQL in (say) Oracle to init system tables as much as possible rather than have them built by internal magic is slow, but for active users a lot less annoying than destroying and rebuilding your database with each and every release, as is necessary when upgrading Postgres. Many changes could be accomplished with judicious updates and inserts into system tables via SQL.
So Lamar can count on my support on the PG upgrade issue when it next arises (Ned Lilly might be a useful point of attack on this one, Lamar, Great Bridge seems more sensitive to broad-based user needs than the developer's group has been traditionally).
But upgrading an existing ACS installation automatically isn't really possible, as Ben mentions. Among other things, the current implementation of "alter table" is too weak to make it possible in the general case even if customization issues were moot (which they aren't, of course).
And a quick install to get things underway is what folks really need. You can't customize without digging under the hood, so by the time upgrading is necessary the user should be pretty familiar with the pieces. Upgrade .sql scripts are something we should supply, but I at least would never want to run them via an automatic script, at least not until having studied them to see how they interact with my customizations. It is very common when customizing the ACS to create tables which relate to "users" and similar core tables, so upgrades need to be studied before they're applied in all but the most trivial circumstances.
When I get back in October, I'll be willing to help out a bit on this project, at least to the extent of helping to test RPMs and review/help with documentation (I don't know anything about how they're built and created and am not all that eager to learn that level of detail).
