[M3devel] multiple pkg roots

[Jay lastname]

Just fyi..I see this all maybe slightly differently.

I'm not sure it works well beyond two pools.

I'm not sure it works well with sparse pools -- particularly if $ORIGIN is used.

Roughly I see it that there are two pools, ROOT/pkg and CM3_INSTALL/pkg.

You build into ROOT/pkg and ship from ROOT/pkg to CM3_INSTALL/pkg.

Ship, or promote, is possibly an entire pkg store to pkg store operation, not individual packages.

 

 

If you remove the use of origin, then it might become easier to use multiple pools

and sparse pool, however, imagine you build and ship a private m3core.so.

Which programs and .so files are supposed to use that?

If that is only the thing you build/ship, nothing will use it.

 

 

Arguably that is correct, since nothing has been built against its possibly changed

interfaces.

 

 

Arguably all pools must be built up from the bottom of the dependency tree and on up.

And the only allowed "sparseness" is that you don't "finish".

 

 

This strikes at why you can't ship after buildlocal.

That isn't the right restriction -- if you buildlocal "everything", then you have coherence

and should be able to ship everything (but not selectively).

 

 

However, now I painted ourselves into a perhaps less interesting corner and in fact

the same place we already are -- you can always build up a new package store from

scratch from the bottom of the dependency tree and on up.

You can always put together a system as non-root.

 

 

Now, let's consider if $ORIGIN is removed.

In fact, by default we use $ORIGIN and full paths.

 

 

Now you can have sparse or incomplete package stores but you have to be careful.

I'm not sure how to formulate what the restrictions are, but for example, if you

were to build and ship out of dependency order, you could end up with a system

where multiple versions of the "same" .so files are in use, and it might or might not matter.

 

 

You could have

pkg1/m3core.so

pkg1/libm3.so

 

pkg2/m3core.so

pkg2/libm3.so

pkg2/libfoo.so

pkg2/libbar.so

 

 

libbar.so might depend on pkg1/libm3.so and pkg1/m3core.so

and libfoo.so might depend on pkg2/libm3.so, pkg2/m3core.so.

Depending on the order you built/shipped in.

If libbar.so and libfoo.so never pass types to each other defined in m3core, then this is probably ok.

However you might end up with multiple garbage collectors trying to free the same storage.

 

 

I suggested that each package store be created by cloning the next one in the list.

That helps address these situations.

But "clone" vs. build from scratch from the bottom of the dependency tree and on up are,

are similar.

 

 

 - Jay

 
> Date: Mon, 6 Jul 2009 11:49:21 -0700
> From: eiserlohpp at yahoo.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] M3devel Digest, Vol 33, Issue 25
> 
> 
> Hi Olaf,
> 
> 
> > Date: Fri, 03 Jul 2009 11:22:05 +0200
> > From: Olaf Wagner <wagner at elegosoft.com>
> > Subject: [M3devel] Some comments about package structure
> > and package
> > pools, was:
> > Re: ROOT
> > To: m3devel at elegosoft.com
> > Message-ID: <20090703112205.3whicg4bw40ok0sk at mail.elegosoft.com>
> > Content-Type: text/plain; charset=ISO-8859-15;
> 
> 
> >The CM3 builder needs to be extended to search a set of pools
> >instead of just one (INSTALL_ROOT). This could be expressed by
> >a CM3_POOL_PATH, similar to the Java class path:
> >
> > CM3_POOL_PATH=/home/wagner/cm3:/home/projects/banana/cm3:/usr/local/cm3
> 
> Yes, I like it. I could then ship my data reduction
> libraries to an appropriate "pool", and then all the
> different programs that make use of those libraries,
> can access them. This would not require "root" privileges.
> If this were a work group pool, then it would only need
> "group" ones. If a private pool such as ${HOME}/m3work
> (the old WDROOT), I wouldn't need any special privileges.
> 
> How would we specify the pool to which we desire to ship?
> Command line argument?
> 
> --pool-install-path=${MYPROJECT}/m3pool
> -p ${MYPROJECT}/m3pool
> 
> Environment Variable?
> M3_INSTALL_POOL=${MYPROJECT}/m3pool
> 
> 
> >
> >To satisfy package imports, the builder would start searching in the
> >first pool and continue until it has found an appropriate package.
> >This way local or project changes could easily be tested and integrated
> >before being `promoted' to a higher level.
> >
> >For backward compatibility reasons, there should be a default pool
> >(/usr/local/cm3) which is used when nothing else is defined.
> 
> We could also make use of the paths built into M3Config,
> as part of the default search pool path. That is the
> reason that M3Config exists, so M3 programs can find at
> run-time the main installation pool, and its components
> (bin, lib, pkg, ..., etc).
> 
> 
> +--------------------------------------------------------+
> | Peter P. Eiserloh |
> +--------------------------------------------------------+
> 
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090706/289c5683/attachment-0002.html>