Adding stuff like this to the info file and the APM package builder pages are very easy, I'd very much prefer we stick to the info file paradigm.
OK, you've confirmed that [ad_conn subsite_id] is one of the things that needs setting ...
.LRN sets the default master by a kludge, it assumes it is mounted under the main subsite and changes its default master parameter behind its back.
If we could define it as a subsite package it wouldn't have to do that, so you've just indentified something we could clean up once we have this facility. A small improvement but a very nice one, IMO.
So, yes, this is functionality you don't get by just visiting a mounted package that we don't call a "subsite". IIRC default master is driven off the [ad_conn subsite_id], ideally everything of this sort should be, if not at the moment, then someday.
APPROVE if it's spec'd in the .info file. If not, I need further convincing ...
Oh ... why do we need a subsite_packages table? If this is designated in the .info file then we can extract whether or not the package is a subsite when we mount just like the other "what kind of package am I?" attributes, and mark the node as a subsite node in the site map table, no? Add a column to that table, in other words...
Then any code which might be interested in whether or not a particular node is a subsite could tell by checking the site map table ...
This would make it possible to control the behavior on a per-instance basis, too ... now I'm getting a bit ambitious, but it would be slick if the portals package could be mounted as a subsite package (after the proper support's written) while also allowing it to function as a subsystem mated to .LRN.
Hmmm...probably should keep your proposal simple for now, though.
