Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-osx
Navigation:
Lists: gentoo-osx: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-osx@g.o
From: Finn Thain <fthain@...>
Subject: Re: Re: [RFC] Separate alt-prefix repo for base-system packages.
Date: Tue, 30 Aug 2005 21:33:36 +1000 (EST)

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@g.o mailing list


Replies:
Re: Re: [RFC] Separate alt-prefix repo for base-system packages.
-- Brian Harring
References:
Re: [RFC] Separate alt-prefix repo for base-system packages.
-- Grobian
Re: [RFC] Separate alt-prefix repo for base-system packages.
-- Finn Thain
Re: Re: [RFC] Separate alt-prefix repo for base-system packages.
-- Kito
Re: Re: [RFC] Separate alt-prefix repo for base-system packages.
-- Finn Thain
Re: Re: [RFC] Separate alt-prefix repo for base-system packages.
-- Brian Harring
Navigation:
Lists: gentoo-osx: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Re: [RFC] Separate alt-prefix repo for base-system packages.
Next by thread:
Re: Re: [RFC] Separate alt-prefix repo for base-system packages.
Previous by date:
package.mask files in 10.4 and 10.3 profiles
Next by date:
Re: Re: [RFC] Separate alt-prefix repo for base-system packages.


Updated Jun 17, 2009

Summary: Archive of the gentoo-osx mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.