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. Yes, app-install is or was not even good for a single install, multiple ones made it useful. But the basic ideas follow along with Malte's comment: provide the needed files in a known location and let the installer download them. That is a big part of the frustration is just locating the right file, then discovering I need CVS access. Try to locate the cvs instructions, etc.
When it comes to installation scripts, my interest is in developing a hierarchical system for very obvious reasons: divide and conquer. Each tiny piece is relatively easy to install, but if you have to coordinate it with other components, do it for multiple systems and maintain it over time, a mega-script becomes a liability. The hierarchical division of scripts should allow the script maintainers to copy the component scripts, make minor variations as needed for new versions and system differences, and provide expert chosen defaults. And as suggested, record the process so the process can be quickly reviewed by the community instead of needing to ask a bunch of questions or make assumptions about what might have happened.
Malte: does a full checkout of the latest release...you mean the CVS version, not a tar.gz file somewhere? This is a good point, a trap I fell into a month ago. Since then I started using git-cvsimport to maintain an easier to browse repository. One very nice feature of this is the 'snapshot'. It is a tar.gz file of whatever sub-directory you want, minus the CVS directories. It is what I would call 'instant publication.'
