Jeff Johnson wrote:
> 
> You've described the name spaces.
> 
> What is kinda hard to infer is the context of name usages.
> 
> rpm (and packages) should not be aware of install context. Installers
> should
> choose context.
> 
> The policy rules above (imho) should be implemented with different
> transactions,

Thats more or less what was done.  Either of the common, host, cross,
target had their own RPM "interfaces" that made sure the right set of
rules was being used for the install (and the right database!)

It was not a situation where you could call a single "rpm" and install
host, cross and common packages at the same time.  The installer first
installed all common packages, then all host packages, then all cross
packages, then all target packages.

> each of which can include (or not) multiple and different rpmdb's, each
> transaction
> should have a constant set of rpmdb's to use. If up to me, I'd open the
> first rpmdb
> RDWR for installing, assume the others are RDONLY.

That is definitely a reasonable thing to do here.

> If the goal is
>     Slop all the pkgs into a single transaction and let rpm sort out the
> mess.
> well, that is a whole different problem space than having multiple
> databases.

No, and maybe thats where I wasn't clear in the past.  The access to
each database was separated so you could not combine the elements into a
single transaction.  (if you wants to do that there was an external
installer that would separate the "command line" into different
transactions using the correct "rpm" instance.)

> One would have to associate name spaces with packages and rpmdb's, and use
> attribute affinity to choose which of multiple rpmdb's a given header
> should
> be installed in.
> 
> Doable afaict (but waving my hands) if/when the time comes.

Ya no intention to have rpm do the heavy lifting of the "where to
install", but be able to do the lifting of "these are the places I need
to check BEFORE I do a runtime probe..."  And the idea of a
corresponding name space.  A good example of "why" is "bash".  A package
may require "bash".  So anything providing "bash" (all the way up to and
including the host system software) is OK here.

However, if there was something "custom" in our included version of
bash.. then "common(bash)" would be required.  This would indicate the
item can't work w/ the system bash, but MUST have the version of bash
installed in "common".


That IMHO is really where the name spaces come in handy.. (and could be
resolved by simply naming the package "common-bash" and requiring the same.)

--Mark