Re: [gentoo-osx] Re: [RFC] Separate alt-prefix repo for base-system packages.

[Brian Harring]

On Wed, Aug 31, 2005 at 01:32:04AM +1000, Finn Thain wrote:
> > > > 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