Override
ASP is similar in all respects to containers ScienceTools, GlastRelease and CHS with one notable exception: it depends on ScienceTools, another full-fledged container, more or less as if it were an external library. When building or running ASP, one must have access to ScienceTools installed files (includes, libraries, python scripts). This is just the way an override directory behaves. The base installation is (or should be) read-only and packages in the override directory may access any of the installed products from the base directory, as well as files installed under the override directory.
In the "normal" use of override, all or most of the override packages are developer versions of packages which already exist in the base directory, but that's not a requirement. In the case of the ASP override directory there would be no packages in common.
So far we know of one detail in the way override directories are treated which doesn't have quite the right behavior for the ASP situation, but there is a simple way to extend the existing behavior to suit the new situation as well as the old. There may be other small glitches; we don't expect anything major.
What is where
scons.package