1 |
On Tue, 30 Aug 2005, Brian Harring wrote: |
2 |
|
3 |
> On Tue, Aug 30, 2005 at 09:33:36PM +1000, Finn Thain wrote: |
4 |
> > On Mon, 29 Aug 2005, Brian Harring wrote: |
5 |
> > |
6 |
> <inserting the relevant quote> |
7 |
> > > > I was thinking of something like, at run time, query the vendor |
8 |
> > > > package manager and use the result to populate the tree with |
9 |
> > > > packages like vendor-apple/sys-devel/xcode-1.5, |
10 |
> > > > vendor-sun/app-arch/cpio-x.y.z for example (please substitute sgi, |
11 |
> > > > bsd-ports, redhat or debian etc if you are hostile to any of my |
12 |
> > > > examples). |
13 |
> > > |
14 |
> > > The rewrite's domain's abstraction (additionally the goal of binding |
15 |
> > > the resolver to the domain, and being able to do inter-domain |
16 |
> > > resolving) would allow for this, but I *really* don't think it'll |
17 |
> > > work well. |
18 |
> > > |
19 |
> > > Reasoning is, how do you know that pkg xyz is actually the package |
20 |
> > > you're after? |
21 |
> Re-inserted the quote to clarify what I'm talking about; mapping another |
22 |
> pkg managers db into our own requires either a lot of human |
23 |
> intervention, or some dodgy rules that somewhat manage it, with bugs. |
24 |
|
25 |
OK, I see what you mean. You're asking, how does portage know that vendor |
26 |
package xyz is the portage package abc? |
27 |
|
28 |
Short answer is package.mask, meta-packages and name mapping. |
29 |
|
30 |
A particular vendor package version is a known-good dep, as tested by |
31 |
devs, otherwise it is masked. E.g. package.mask says |
32 |
>vendor-sun/app-arch/cpio-x.y.z if no higher version has been tested. In |
33 |
mac os, automated updates mean that most of the time, there will be some |
34 |
vendor packages that the tree hasn't been tested against. These have to be |
35 |
masked until the user does emerge sync. |
36 |
|
37 |
Another part of the problem is solved by meta-packages. If the vendor dep |
38 |
is still masked after emerge sync, it can't be used, and the next most |
39 |
"package.preferred" dep will be built and installed straight from the tree |
40 |
(on a prefix). Once the vendor dep is unmasked, depclean will remove it |
41 |
again. |
42 |
|
43 |
Virtuals/meta-packages already permit a bit of slack. The packages that |
44 |
provide a virtual are not the same, of course, so any ebuild using a |
45 |
virtual/meta-package as a dep is not going to be too fussy (e.g. needs awk |
46 |
but not gnu extensions). vendor packages are a good fit here. |
47 |
|
48 |
> > Not sure I understand the problem... in glep 37, a virtual is replaced |
49 |
> > with a meta-package having a list of depends alternatives. If you add |
50 |
> > the vendor package to that list, and then make the vendor packages |
51 |
> > "package.preferred" where portage is a secondary package manager, |
52 |
> > surely there is no question that package xyz is the one you're after? |
53 |
> > |
54 |
> > (I'm assuming all repos share the same namespace WRT package names... |
55 |
> > if cpv's do not have to be unique accross repos, other solutions might |
56 |
> > be possible...) |
57 |
> If you're managing a list of provided packages, my points don't matter; |
58 |
> points were strictly in reference to trying to have portage query |
59 |
> another pkg manager (primary or otherwise) :) |
60 |
|
61 |
BTW, do repos share a namespace? Presented with the same cpv in several |
62 |
repos, is portage's behaviour defined yet? |
63 |
|
64 |
> > > The expanded restrictions subsystem, specifically ability to depends |
65 |
> > > based on contents restrictions (I want the pkg that owns file abc |
66 |
> > > essentially) gives basic ability for this |
67 |
> > |
68 |
> > I don't understand why portage would go looking for deps in the |
69 |
> > filesystem. If configure can't find them, does it help that portage |
70 |
> > can? |
71 |
> Quote above is in reference to the (potentially incorrectly perceived) |
72 |
> idea of directly querying another pkg manager. |
73 |
> |
74 |
> > The last I read about this was here... |
75 |
> > http://article.gmane.org/gmane.linux.gentoo.devel/28154 I guess there |
76 |
> > is more too it? |
77 |
> Haubi's glep/patches were moreso for pulling off shifted presets, |
78 |
> relevant to the shifted preset goal's y'all have, but not pertinent to |
79 |
> portion of the discussion involving attempting to query apple's |
80 |
> installed db (which is the proposal you put forth) :) |
81 |
> |
82 |
> > But, generating package.provided with a wrapper is a hack, so long |
83 |
> > term, a vendor package manager (or a shim on top of it) |
84 |
> My question/concerns raised have been regarding the potential |
85 |
> shim/wrapper. How do you wrap their pkg manager's namespace into |
86 |
> portages namespace? To do so you need to either manage a list of |
87 |
> mappings yourself, or come up with rules (which will have exceptions). |
88 |
|
89 |
My feeling is that the burden of managing the mappings is better than the |
90 |
burden of managing one package.provided for mac os 10.3, alongside another |
91 |
for 10.4, etc. (If I'm wrong about that, then this exercise is pointless.) |
92 |
|
93 |
In some cases the mapping is trivial: take the closed source XCode |
94 |
package. I would have an ebuild called vendor-apple/sys-devel/xcode-1.5 to |
95 |
install the DeveloperTools.pkg file, from a distfile taken from apple's |
96 |
cd. So this ebuild would contain the forward mapping, by storing the |
97 |
vendor's name in it's env. (Same applies to solaris pkgadd and irix |
98 |
swinst...) |
99 |
|
100 |
So the same ebuild also embodies the reverse mapping, and portage can map |
101 |
a vendor's package-version to the ebuild itself, and populate a vdb with |
102 |
the ebuild's PV. IOW, the ebuilds themselves provide the 1:M mapping of |
103 |
vendor name to portage names. |
104 |
|
105 |
Several vendor packages are sometimes required to make up one of portage's |
106 |
deps (e.g. vendor-apple/x11-base/xfree would comprise both of X11SDK.pkg |
107 |
and X11User.pkg). That ebuild would install two vendor packages and |
108 |
contain two vendor names (basically an N:1 mapping). |
109 |
|
110 |
Now, what if there is no ebuild to match a vendor package? No mapping. Dep |
111 |
has to come from the tree instead. Not a big deal for a secondary package |
112 |
manager. |
113 |
|
114 |
But what if you want dev-tcltk/tcllib to satisfy an explicit dep on |
115 |
vendor-apple/dev-tcltk/tcllib? You can't. But I can't see this being a |
116 |
problem. (Though, you could have a metapackage for tcllib and |
117 |
package.prefer dev-tcltk/tcllib in your profile.) |
118 |
|
119 |
I would say that explicit deps on vendor packages can be avoided whereever |
120 |
said package is open source and we have an ebuild to build it. |
121 |
|
122 |
Of the open source stuff, those packages that are built from vendor |
123 |
sources (or patches), are not "vendor packages" in the sense I've used the |
124 |
term, that is, they don't get installed by a foriegn package manager, and |
125 |
they don't live under /vendor-*. They are just regular ebuilds. |
126 |
|
127 |
> That's what I'm getting at; people don't support interop between dpkg |
128 |
> and rpm (fex) due to the fact the namespaces are different (although |
129 |
> it's possible to do so if you account for abi). |
130 |
> |
131 |
> > I probably need a better handle on the constraints of the relations |
132 |
> > between domains, repos, prefixes... anyway, here is my naive partial |
133 |
> > config. This config is premature, of course, but it might help me |
134 |
> > understand what is and is not possible in the rewrite if you would |
135 |
> > kindly shoot some holes in it ;-) |
136 |
> > |
137 |
> > Notes: I've used a hypothetical feature for collecting information |
138 |
> > about vendor packages -- presumably the apple domain also needs an |
139 |
> > ephemeral vdb to hold it (like package.provided). I don't know if this |
140 |
> > vendor domain needs a repo. I guess the main repo would have to mask |
141 |
> > broken/testing vendor deps as it sees fit, including those from other |
142 |
> > domains... |
143 |
> Offhand, what you're proposing (querying the vendor installed pkg db) is |
144 |
> actually a readonly vdb, if it were implemented. It's an installed |
145 |
> package database you can query (use for solving deps), but cannot |
146 |
> modify. |
147 |
> |
148 |
> > [vendor-apple] type = config FEATURES = "query-apple-packages" |
149 |
> > ACCEPT_KEYWORDS = "ppc-darwin" |
150 |
> Definitions not totally right as mentioned (doesn't matter, just being |
151 |
> nitpicky :), but the crux of my concern is embodied inthe |
152 |
> FEATURES="query-apple-packages". |
153 |
> |
154 |
> Mainly, how? How to query the vendor db, and map that back into portage |
155 |
> package namespace? |
156 |
|
157 |
Did I read something about the rewrite being modular? Could the shim/query |
158 |
take the form of a portage plugin that implements the query-apple-packages |
159 |
feature? Obviously, if implemented the way I descibed above, it would need |
160 |
to be intimate with certain ebuilds' environments. |
161 |
|
162 |
-f |
163 |
|
164 |
> |
165 |
> ~harring |
166 |
> |
167 |
-- |
168 |
gentoo-osx@g.o mailing list |