<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Just fyi..I see this all maybe slightly differently.<BR>
I'm not sure it works well beyond two pools.<BR>
I'm not sure it works well with sparse pools -- particularly if $ORIGIN is used.<BR>
Roughly I see it that there are two pools, ROOT/pkg and CM3_INSTALL/pkg.<BR>
You build into ROOT/pkg and ship from ROOT/pkg to CM3_INSTALL/pkg.<BR>
Ship, or promote, is possibly an entire pkg store to pkg store operation, not individual packages.<BR>
<BR>
<BR>
If you remove the use of origin, then it might become easier to use multiple pools<BR>
and sparse pool, however, imagine you build and ship a private m3core.so.<BR>
Which programs and .so files are supposed to use that?<BR>
If that is only the thing you build/ship, nothing will use it.<BR>
<BR>
<BR>
Arguably that is correct, since nothing has been built against its possibly changed<BR>
interfaces.<BR>
<BR>
<BR>
Arguably all pools must be built up from the bottom of the dependency tree and on up.<BR>
And the only allowed "sparseness" is that you don't "finish".<BR>
<BR>
<BR>
This strikes at why you can't ship after buildlocal.<BR>
That isn't the right restriction -- if you buildlocal "everything", then you have coherence<BR>
and should be able to ship everything (but not selectively).<BR>
<BR>
<BR>
However, now I painted ourselves into a perhaps less interesting corner and in fact<BR>
the same place we already are -- you can always build up a new package store from<BR>
scratch from the bottom of the dependency tree and on up.<BR>
You can always put together a system as non-root.<BR>
<BR>
<BR>
Now, let's consider if $ORIGIN is removed.<BR>
In fact, by default we use $ORIGIN and full paths.<BR>
<BR>
<BR>
Now you can have sparse or incomplete package stores but you have to be careful.<BR>
I'm not sure how to formulate what the restrictions are, but for example, if you<BR>
were to build and ship out of dependency order, you could end up with a system<BR>
where multiple versions of the "same" .so files are in use, and it might or might not matter.<BR>
<BR>
<BR>
You could have<BR>
pkg1/m3core.so<BR>
pkg1/libm3.so<BR>
<BR>
pkg2/m3core.so<BR>
pkg2/libm3.so<BR>
pkg2/libfoo.so<BR>
pkg2/libbar.so<BR>
<BR>
<BR>
libbar.so might depend on pkg1/libm3.so and pkg1/m3core.so<BR>
and libfoo.so might depend on pkg2/libm3.so, pkg2/m3core.so.<BR>
Depending on the order you built/shipped in.<BR>
If libbar.so and libfoo.so never pass types to each other defined in m3core, then this is probably ok.<BR>
However you might end up with multiple garbage collectors trying to free the same storage.<BR>
<BR>
<BR>
I suggested that each package store be created by cloning the next one in the list.<BR>
That helps address these situations.<BR>
But "clone" vs. build from scratch from the bottom of the dependency tree and on up are,<BR>
are similar.<BR>
<BR>
<BR>
- Jay<BR><BR> <BR>> Date: Mon, 6 Jul 2009 11:49:21 -0700<BR>> From: eiserlohpp@yahoo.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] M3devel Digest, Vol 33, Issue 25<BR>> <BR>> <BR>> Hi Olaf,<BR>> <BR>> <BR>> > Date: Fri, 03 Jul 2009 11:22:05 +0200<BR>> > From: Olaf Wagner <wagner@elegosoft.com><BR>> > Subject: [M3devel] Some comments about package structure<BR>> > and package<BR>> > pools, was:<BR>> > Re: ROOT<BR>> > To: m3devel@elegosoft.com<BR>> > Message-ID: <20090703112205.3whicg4bw40ok0sk@mail.elegosoft.com><BR>> > Content-Type: text/plain; charset=ISO-8859-15;<BR>> <BR>> <BR>> >The CM3 builder needs to be extended to search a set of pools<BR>> >instead of just one (INSTALL_ROOT). This could be expressed by<BR>> >a CM3_POOL_PATH, similar to the Java class path:<BR>> ><BR>> > CM3_POOL_PATH=/home/wagner/cm3:/home/projects/banana/cm3:/usr/local/cm3<BR>> <BR>> Yes, I like it. I could then ship my data reduction<BR>> libraries to an appropriate "pool", and then all the<BR>> different programs that make use of those libraries,<BR>> can access them. This would not require "root" privileges.<BR>> If this were a work group pool, then it would only need<BR>> "group" ones. If a private pool such as ${HOME}/m3work<BR>> (the old WDROOT), I wouldn't need any special privileges.<BR>> <BR>> How would we specify the pool to which we desire to ship?<BR>> Command line argument?<BR>> <BR>> --pool-install-path=${MYPROJECT}/m3pool<BR>> -p ${MYPROJECT}/m3pool<BR>> <BR>> Environment Variable?<BR>> M3_INSTALL_POOL=${MYPROJECT}/m3pool<BR>> <BR>> <BR>> ><BR>> >To satisfy package imports, the builder would start searching in the<BR>> >first pool and continue until it has found an appropriate package.<BR>> >This way local or project changes could easily be tested and integrated<BR>> >before being `promoted' to a higher level.<BR>> ><BR>> >For backward compatibility reasons, there should be a default pool<BR>> >(/usr/local/cm3) which is used when nothing else is defined.<BR>> <BR>> We could also make use of the paths built into M3Config,<BR>> as part of the default search pool path. That is the<BR>> reason that M3Config exists, so M3 programs can find at<BR>> run-time the main installation pool, and its components<BR>> (bin, lib, pkg, ..., etc).<BR>> <BR>> <BR>> +--------------------------------------------------------+<BR>> | Peter P. Eiserloh |<BR>> +--------------------------------------------------------+<BR>> <BR>> <BR>> <BR>> <BR></body>
</html>