I wrote some scripts which run through on most systems that will give you OpenACS, AOLserver without interfering with your local setup. I did not add PostgreSQL to the mix as this is probably installed already (albeit I have to pray the settings are right and the version works with OpenACS 😊).
Judging from this experience and the fact that I did over 100 installations in the last six months, here is what might work:
Create a script which does the downloading and compiling. It should check if it is able to connect to PG on 5432 and if yes, check that the version works with OpenACS (otherwise stop and return an error). If no, install PG on it's own. I am not a friend of letting the user make decisions in the install process so I would make some default assumptions based on the experience collected so far (e.g. install in /usr/local instead of /opt, use /var/lib/aolserver instead of /opt or /web), openacs as the service name, localhost using the first available port above 8000.
If this would help I can ask my sysadmins to write such a script based on the scripts that I have written so far. Sadly, I am not sure how much support we can guarantee for the script to work on all kinds of platforms, though we would try to make as many "if" statements into it to enable it on even more platforms.
This being said, I totally agree with Tom about the configuration and running part. If all you want is to try out OpenACS and add some more modules using the installer then you should be fine. But it starts with the basic question of "Do you want to install .LRN" which has a significant implication on the install. Furthermore, having the modules installed without and data in them is nice, yet you will wish for more so you can play around with it.
Project/Open ]po[ has gone a nice way here in providing a prefilled dump file with the ability to delete all demo data. That is their way of installing and at the moment they do not have a configuration file which does all the configurations necessary for a normally running system. Same way is what Quest did with their AIMS application. So the next question (assuming you got OpenACS installed), which dumpfile to use. And who is going to provide such a dumpfile for the installation, what should be included? We could probably provide a dump with the minimal components installed, all empty. But will this be enough for the user to get an experience out of OpenACS. And who is the user anyway? Is it the end user evaluating the product for his website like a canned product? Or is it the developer who wants to install this for one of their clients?
The app-install approach works perfect for the developer. As for the end user like Vic says he is, we should probably provide dump files for simple OpenACS, .LRN and maybe whatever combination people are willing to provide dump files for.
Either way, the codebase should be a full checkout of the latest release branch.
