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: Brian Harring <ferringb@g.o>
Subject: Re: Re: [RFC] Separate alt-prefix repo for base-system packages.
Date: Tue, 30 Aug 2005 08:07:58 -0500
On Tue, Aug 30, 2005 at 09:33:36PM +1000, Finn Thain wrote:
> On Mon, 29 Aug 2005, Brian Harring wrote:
> 
<inserting the relevant quote>
> > > I was thinking of something like, at run time, query the vendor package
> > > manager and use the result to populate the tree with packages like
> > > vendor-apple/sys-devel/xcode-1.5, vendor-sun/app-arch/cpio-x.y.z for
> > > example (please substitute sgi, bsd-ports, redhat or debian etc if 
> > > you are hostile to any of my examples).
> >
> > 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?
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.

> 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...)
If you're managing a list of provided packages, my points don't 
matter; points were strictly in reference to trying to have portage 
query another pkg manager (primary or otherwise) :)

> > 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?
Quote above is in reference to the (potentially incorrectly perceived) 
idea of directly querying another pkg manager.

> The last I read about this was here...
> http://article.gmane.org/gmane.linux.gentoo.devel/28154
> I guess there is more too it?
Haubi's glep/patches were moreso for pulling off shifted presets, 
relevant to the shifted preset goal's y'all have, but not pertinent to 
portion of the discussion involving attempting to query apple's 
installed db (which is the proposal you put forth) :)

> But, generating package.provided with a wrapper is a hack, so long term, a 
> vendor package manager (or a shim on top of it)
My question/concerns raised have been regarding the potential 
shim/wrapper.  How do you wrap their pkg manager's namespace into 
portages namespace?  To do so you need to either manage a list of 
mappings yourself, or come up with rules (which will have exceptions).

That's what I'm getting at; people don't support interop between dpkg 
and rpm (fex) due to the fact the namespaces are different (although 
it's possible to do so if you account for abi).

> 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...
Offhand, what you're proposing (querying the vendor installed pkg db) 
is actually a readonly vdb, if it were implemented.
It's an installed package database you can query (use for solving 
deps), but cannot modify.

> [vendor-apple]
> type = config
> FEATURES = "query-apple-packages"
> ACCEPT_KEYWORDS = "ppc-darwin"
Definitions not totally right as mentioned (doesn't matter, just being 
nitpicky :), but the crux of my concern is embodied inthe 
FEATURES="query-apple-packages".

Mainly, how?  How to query the vendor db, and map that back into 
portage package namespace?

~harring
Attachment:
pgppPxwrNyzi6.pgp (PGP signature)
Replies:
Re: Re: [RFC] Separate alt-prefix repo for base-system packages.
-- Finn Thain
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
Re: Re: [RFC] Separate alt-prefix repo for base-system packages.
-- Finn Thain
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:
Re: Re: [RFC] Separate alt-prefix repo for base-system packages.
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.