Forum OpenACS Q&A: Response to Enhancing the Installation Process: Automation.
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).