1 |
On Tue, Aug 30, 2005 at 09:33:36PM +1000, Finn Thain wrote: |
2 |
> On Mon, 29 Aug 2005, Brian Harring wrote: |
3 |
> |
4 |
<inserting the relevant quote> |
5 |
> > > I was thinking of something like, at run time, query the vendor package |
6 |
> > > manager and use the result to populate the tree with packages like |
7 |
> > > vendor-apple/sys-devel/xcode-1.5, vendor-sun/app-arch/cpio-x.y.z for |
8 |
> > > example (please substitute sgi, bsd-ports, redhat or debian etc if |
9 |
> > > you are hostile to any of my examples). |
10 |
> > |
11 |
> > The rewrite's domain's abstraction (additionally the goal of binding the |
12 |
> > resolver to the domain, and being able to do inter-domain resolving) |
13 |
> > would allow for this, but I *really* don't think it'll work well. |
14 |
> > |
15 |
> > Reasoning is, how do you know that pkg xyz is actually the package |
16 |
> > you're after? |
17 |
Re-inserted the quote to clarify what I'm talking about; mapping |
18 |
another pkg managers db into our own requires either a lot of human |
19 |
intervention, or some dodgy rules that somewhat manage it, with bugs. |
20 |
|
21 |
> Not sure I understand the problem... in glep 37, a virtual is replaced |
22 |
> with a meta-package having a list of depends alternatives. If you add the |
23 |
> vendor package to that list, and then make the vendor packages |
24 |
> "package.preferred" where portage is a secondary package manager, surely |
25 |
> there is no question that package xyz is the one you're after? |
26 |
> |
27 |
> (I'm assuming all repos share the same namespace WRT package names... if |
28 |
> cpv's do not have to be unique accross repos, other solutions might be |
29 |
> possible...) |
30 |
If you're managing a list of provided packages, my points don't |
31 |
matter; points were strictly in reference to trying to have portage |
32 |
query another pkg manager (primary or otherwise) :) |
33 |
|
34 |
> > The expanded restrictions subsystem, specifically ability to depends |
35 |
> > based on contents restrictions (I want the pkg that owns file abc |
36 |
> > essentially) gives basic ability for this |
37 |
> |
38 |
> I don't understand why portage would go looking for deps in the |
39 |
> filesystem. If configure can't find them, does it help that portage can? |
40 |
Quote above is in reference to the (potentially incorrectly perceived) |
41 |
idea of directly querying another pkg manager. |
42 |
|
43 |
> The last I read about this was here... |
44 |
> http://article.gmane.org/gmane.linux.gentoo.devel/28154 |
45 |
> I guess there is more too it? |
46 |
Haubi's glep/patches were moreso for pulling off shifted presets, |
47 |
relevant to the shifted preset goal's y'all have, but not pertinent to |
48 |
portion of the discussion involving attempting to query apple's |
49 |
installed db (which is the proposal you put forth) :) |
50 |
|
51 |
> But, generating package.provided with a wrapper is a hack, so long term, a |
52 |
> vendor package manager (or a shim on top of it) |
53 |
My question/concerns raised have been regarding the potential |
54 |
shim/wrapper. How do you wrap their pkg manager's namespace into |
55 |
portages namespace? To do so you need to either manage a list of |
56 |
mappings yourself, or come up with rules (which will have exceptions). |
57 |
|
58 |
That's what I'm getting at; people don't support interop between dpkg |
59 |
and rpm (fex) due to the fact the namespaces are different (although |
60 |
it's possible to do so if you account for abi). |
61 |
|
62 |
> I probably need a better handle on the constraints of the relations |
63 |
> between domains, repos, prefixes... anyway, here is my naive partial |
64 |
> config. This config is premature, of course, but it might help me |
65 |
> understand what is and is not possible in the rewrite if you would kindly |
66 |
> shoot some holes in it ;-) |
67 |
> |
68 |
> Notes: I've used a hypothetical feature for collecting information about |
69 |
> vendor packages -- presumably the apple domain also needs an ephemeral vdb |
70 |
> to hold it (like package.provided). I don't know if this vendor domain |
71 |
> needs a repo. I guess the main repo would have to mask broken/testing |
72 |
> vendor deps as it sees fit, including those from other domains... |
73 |
Offhand, what you're proposing (querying the vendor installed pkg db) |
74 |
is actually a readonly vdb, if it were implemented. |
75 |
It's an installed package database you can query (use for solving |
76 |
deps), but cannot modify. |
77 |
|
78 |
> [vendor-apple] |
79 |
> type = config |
80 |
> FEATURES = "query-apple-packages" |
81 |
> ACCEPT_KEYWORDS = "ppc-darwin" |
82 |
Definitions not totally right as mentioned (doesn't matter, just being |
83 |
nitpicky :), but the crux of my concern is embodied inthe |
84 |
FEATURES="query-apple-packages". |
85 |
|
86 |
Mainly, how? How to query the vendor db, and map that back into |
87 |
portage package namespace? |
88 |
|
89 |
~harring |