Unfortunately OpenACS relies on many packages which the OpenACS community cannot demand be maintained, and available in rpm, etc. format. To require this is to say no to an auto installer.
Even OpenACS doesn't have a standard which adequately addresses running multiple independent installations on the same machine.
You only install sendmail once, same with qmail, daemontools, and a bunch of other standard packages. It makes sense to have rpms for these singleton packages. However AOLserver and OpenACS and PostgreSQL are often installed in multiple locations on the same machine. Plus you have to address the possibility that a user might not have root access to their machine and might want to install OpenACS with their own privileges.
Even if rpm packages existed, you still need to maintain an installation document to explain how to do the install. Users still have to find and deal with the same issues. What is needed is a tool to combine installations of multiple independent software products.
Also, note that it isn't rocket science to install any individual package. Most of the time is spent figuring out what options to use to ./configure, how to do the post install configuration, etc. The problem is in glueing the packages togeather (plus finding the up-to-date packages is a pita). OpenACS installation itself couldn't be easier, and with 5.0 it seemed to get even easier.
It is possible something as simple as 'configure' and 'gmake' could work. Some AOLserver modules have gmake targets to create release version of the module, so it is obvious it can be used to perform any command line task, handle dependencies, etc.
