> > > > Reasoning is, how do you know that pkg xyz is actually the package
> > > > you're after?
> > Re-inserted the quote to clarify what I'm talking about; mapping another
> > pkg managers db into our own requires either a lot of human
> > intervention, or some dodgy rules that somewhat manage it, with bugs.
>
> OK, I see what you mean. You're asking, how does portage know that vendor
> package xyz is the portage package abc?
>
> Short answer is package.mask, meta-packages and name mapping.
>
> A particular vendor package version is a known-good dep, as tested by
> devs, otherwise it is masked. E.g. package.mask says
> >vendor-sun/app-arch/cpio-x.y.z if no higher version has been tested. In
> mac os, automated updates mean that most of the time, there will be some
> vendor packages that the tree hasn't been tested against. These have to be
> masked until the user does emerge sync.

Alright, so I'm just being a tool 'coz I thought you were talking
about dynamic mapping (vs dev managed mappings). Nevermind me :)

> BTW, do repos share a namespace? Presented with the same cpv in several
> repos, is portage's behaviour defined yet?

repo's have their own *total* namespace now; an overlay + repo is
different though since an overlay is slaved to a repo.
<=2.1 basically lacks any true support for N repos; you can have a
portdir(+overlays), a vdb, and a bintree. Rewrite has no such
restriction built into it.

> My feeling is that the burden of managing the mappings is better than the
> burden of managing one package.provided for mac os 10.3, alongside another
> for 10.4, etc. (If I'm wrong about that, then this exercise is pointless.)

Actually, I agree; it's cleaner then just autoassuming stuff is there.

> Did I read something about the rewrite being modular? Could the shim/query
> take the form of a portage plugin that implements the query-apple-packages
> feature? Obviously, if implemented the way I descibed above, it would need
> to be intimate with certain ebuilds' environments.

Well, considering I'm seriously considering when/if rewrite is
released, it's released as two packages; portage-core, and
portage-ebuild... yes. Very modular.
There pretty much is one point of required entry into the code;
getting the config obj- from there it loads the code it needs,
instantiating objects on the fly. Aside from the entry point/config
obj, everything else is intended to be configurable.
~harring