I don't understand what you're saying, except for the last bit.
...enable administrators to bundle/config together various package instances.
The way I seem to be building sites is to create meta-packages that implement the new functionality, and which mount other packages within their URL branch for re-use.
In this case I know exactly where a bboard is and what it's package_id is, as my meta-package mounts it itself and stores away the details.
The only problem I was having was getting dependant packages mounted when my meta-package is mounted from the site map. I think I see the correct solution in apm_post_instantiation_tcl_proc_from_key, but I haven't tried that yet.
As for administrators bundling together packages, that sounds like the problem "How do i transfer my site map and parameter values from dev to production?". I thought someone was looking at that a while ago, Henry..? How about storing the site map in the file system with Apache style .htaccess files which describe which package should be mounted there, and any parameter values..?
My own view is that the package manager doesn't suit our needs. It is not important to package up individual applications into standalone distribution files (*.apm) so that they can be installed willy-nilly. In fact I think it's detremental to the goal of producing an *integrated* tool kit (you don't have to look far to see the wheel re-invention...)
The problems discussed in "How do you separate project customisations from improvements?" are faced by each of us, but we have no tools to help us manage the complexity. A FreeBSD style system using CVS rather than the RedHat style package system we have would be more appropriate.
Anyway... If I wait long enough maybe Don will do it all for me.
