The way to do what Chris and Ben are after is to provide different variants in install.xml (the file that automagically installs .LRN) to make it simple to build custom installs of various packages and to override the default index file with a custom one.
My personal secret plan is to bundle up the blog package, photo album, and similar things into something I've been calling .VANITY (as in the "vanity press", i.e. pay-to-publish press for the vain)
A one-person stand-on-your-soapbox preconfigured install.
Anyway eventually we should be able to allow people to choose between some common configurations if they want. The installer could even provide a select box with options to choose from based on the different default configs provided by install.xml. Currently only one "application" tag is allowed inside install.xml but there's no reason we couldn't provide different "application" tags with configuration data inside the file and ask the user to choose. If only one application is defined it would get autoinstalled without querying the user as is done today for .LRN.
This would support both bundling of single vertical-app tarballs that autoinstall and the choice of several default configurations for the general case.
But we do want to have available a vanilla index page not much different in philosophy from the current one because we still have the developer as a primary target and "real site" builders will be heavily customizing everything.
As far as using ETP ... Lars and I and a couple of others talked at Copenhagen about rewriting acs-subsite to optionally return a portal page or an ETP page instead of the index template. That would leave folks with the possibility per-subsite of
1. return default index template
2. return custom index template (for the main site that's what's done now, the custom index template at /www)
3. return ETP page
4. return portal
One problem with using ETP right now as our default is that it is still be worked on and rewritten to better fit with content repository paradigms among other things.
This will require upgrade scripts. This could present a bit of a chicken-and-egg problem when it comes time to upgrade a running OpenACS site if it is still using ETP as its index page.
I'm not sure we want to introduce that potential complexity right now ...
