I've added code to the installer that causes it to read an optional XML file named "install.xml" in acs_root_dir. If it finds it, interesting things happen. Here's an example:
<?xml version="1.0"?>
<application name="dotlrn" pretty-name=".LRN" home="https://openacs.org/projects/dotlrn">
<actions>
<install package="*"/>
<mount package="dotlrn" mount-point="dotlrn" instance-name="dotLRN"/>
<set-parameter url="/" name="DefaultMaster" value="/packages/dotlrn/www/dotlrn-master"/>
<set-parameter package="acs-kernel" name="IndexRedirectUrl" value="/dotlrn/index"/>
</actions>
</application>
This file declares an application named ".LRN" and some actions to be taken when installation of the core OpenACS toolkit pieces is complete.
The first thing the installer does is to use the "pretty-name" to customize the installer's initial splash page that congratulates the user on choosing OpenACS, checks for proper db configuration etc. It now tells you it will automatically install the specified application for you after core installation is complete. It takes the home URL, builds a link, and tells you to visit it for more information about the application.
The actions above are self explanatory, I assume. Essentially they say "install every package in the tarball, mount dotlrn, and set the specified parameters to the specified values".
The first parameter sets the default master for the main subsite to the dotlrn master template, The second parameter is a new one I've added to the kernel which is now read by our default index page. If set to a non-blank value, the default index page redirects to the given URL.
Hopefully folks can see how this approach will be useful for anyone who wants to bundle up a custom suite of OpenACS packages, deliver them as a single tarball, and have installation be relatively painless for the user.
