1 |
On Tue, 30 Aug 2005, Brian Harring wrote: |
2 |
|
3 |
> On Wed, Aug 31, 2005 at 01:32:04AM +1000, Finn Thain wrote: |
4 |
> |
5 |
> > My feeling is that the burden of managing the mappings is better than |
6 |
> > the burden of managing one package.provided for mac os 10.3, alongside |
7 |
> > another for 10.4, etc. (If I'm wrong about that, then this exercise is |
8 |
> > pointless.) |
9 |
> Actually, I agree; it's cleaner then just autoassuming stuff is there. |
10 |
|
11 |
Thing is, if you undertake to track another package manager in this way, |
12 |
you must expect the worst from the vendor. So the question is, just how |
13 |
robust are such mappings are in the face of upstream mayhem? |
14 |
|
15 |
Here are some scenarios, where I think the present package.provided method |
16 |
seems to work better, |
17 |
|
18 |
1. Vendor changes package manager API. |
19 |
- user will have no vendor deps until devs update the shim |
20 |
|
21 |
2. Vendor renames a package. |
22 |
- user will lose a vendor dep until devs add a new mapping |
23 |
|
24 |
3. Vendor combines two packages. |
25 |
- see 2. |
26 |
|
27 |
4. Vendor bumps a package version. |
28 |
- see 2. |
29 |
|
30 |
And here are some scenarios where the proposed method of mapping & masking |
31 |
is better: |
32 |
|
33 |
5. Vendor splits a package. |
34 |
- existing method loses if any part is no longer installed by default |
35 |
- new method works, given vendor bumps package version |
36 |
|
37 |
6. Vendor drops a package entirely or renders it broken as a dep. |
38 |
- existing method loses. e.g. if this happened in mac os 10.3.9, all |
39 |
10.3 users would have suffered |
40 |
- new method works, given vendor bumps package version |
41 |
|
42 |
7. Vendor fixes a previously broken package |
43 |
- existing method loses. e.g. if this happened in mac os 10.3.9, no |
44 |
10.3 users benefit, because many still do not have the fix |
45 |
- new method works, given vendor bumps package version |
46 |
|
47 |
8. Vendor adds a package already in the tree. |
48 |
- old method loses if the two packages are not equivalent |
49 |
- new method wins if a virtual/metapackage can be used to mean "close |
50 |
enough" |
51 |
|
52 |
9. Vendor adds a package not already in the tree. |
53 |
- old method loses because deprecated profiles (e.g. mac os 10.2) will |
54 |
never get the benefit of that package |
55 |
- new method wins because a new mapping is all that is required |
56 |
|
57 |
As I described it, a mapping is a full mapping from vendor PV to portage |
58 |
PV. So a new mapping is needed when the vendor revs the package (point 4 |
59 |
above). |
60 |
|
61 |
Now, if we could also have an ebuild without a version number, like |
62 |
/opt/gentoo/usr/portage/vendor-apple/sys-devel/xcode/xcode.ebuild, it |
63 |
could just map a vendor name to a portage name. The synthetic vendor |
64 |
package that shows up in the vdb would get the vendor's full version. In |
65 |
this case, the devs' work is lessened because a new mapping wouldn't have |
66 |
to be added every time the vendor revs a package. Instead, package.mask |
67 |
would provide QA. |
68 |
|
69 |
-f |
70 |
-- |
71 |
gentoo-osx@g.o mailing list |