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

[Finn Thain <fthain@telegraphics.com.au>]

On Mon, 29 Aug 2005, Brian Harring wrote:

> The rewrite's domain's abstraction (additionally the goal of binding the 
> resolver to the domain, and being able to do inter-domain resolving) 
> would allow for this, but I *really* don't think it'll work well.
>
> Reasoning is, how do you know that pkg xyz is actually the package 
> you're after?

Not sure I understand the problem... in glep 37, a virtual is replaced 
with a meta-package having a list of depends alternatives. If you add the 
vendor package to that list, and then make the vendor packages 
"package.preferred" where portage is a secondary package manager, surely 
there is no question that package xyz is the one you're after?

(I'm assuming all repos share the same namespace WRT package names... if 
cpv's do not have to be unique accross repos, other solutions might be 
possible...)

> The expanded restrictions subsystem, specifically ability to depends 
> based on contents restrictions (I want the pkg that owns file abc 
> essentially) gives basic ability for this

I don't understand why portage would go looking for deps in the 
filesystem. If configure can't find them, does it help that portage can?

The last I read about this was here...
http://article.gmane.org/gmane.linux.gentoo.devel/28154
I guess there is more too it?

> but it doesn't cover the abi angle.

I hadn't considered the ABI problem. In the short term I think a synthetic 
package.provided is okay, since most multilib machines cater to the 
ABI-ignorant.

But, generating package.provided with a wrapper is a hack, so long term, a 
vendor package manager (or a shim on top of it) would have to state what 
ABI was used for each package, when queried. Knowing the ABIs of the 
vendor packages, and knowing the native ABI of the target domain (?), the 
resolver could probably do the right thing...

> What you're proposing could sort of be hacked together to pull off 
> strictly for src compiles, probably with a good collection of impossible 
> to quash annoying bugs.  Doing it for binaries is a helluva lot harder 
> though. :)

I think these are the bugs which have been the gentoo-osx team's burden 
already... brave souls that they are :-)

> The rewrite's general core is intended to allow for alt 
> formats/repos/whatever jammed into it; that said, making seperate 
> formats play nice with each other (unless they can natively) isn't 
> something I think is incredibly easy to pull off, as mentioned above.
>
> Thoughts?

I probably need a better handle on the constraints of the relations 
between domains, repos, prefixes... anyway, here is my naive partial 
config. This config is premature, of course, but it might help me 
understand what is and is not possible in the rewrite if you would kindly 
shoot some holes in it ;-)

Notes: I've used a hypothetical feature for collecting information about 
vendor packages -- presumably the apple domain also needs an ephemeral vdb 
to hold it (like package.provided). I don't know if this vendor domain 
needs a repo. I guess the main repo would have to mask broken/testing 
vendor deps as it sees fit, including those from other domains...

-f


[vdb]
type = repo
class = portage.installed_pkg.repository
path = 

[rsync repo]
type = repo 
class = portage.ebuild.repository
path = /opt/gentoo/usr/portage

[ppc-macos]
type = config
ACCEPT_KEYWORDS = "ppc-macos"

[default domain]
type = domain
root = "/opt/gentoo"
repositories = 'rsync repo' vdb
config = ppc-macos

[vendor-apple]
type = config
FEATURES = "query-apple-packages"
ACCEPT_KEYWORDS = "ppc-darwin"

[apple domain]
type = domain
root = "/"
config = vendor-apple



-- 
gentoo-osx@gentoo.org mailing list