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
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...
> 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.
> 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
Mainly, how? How to query the vendor db, and map that back into
portage package namespace?