Re: [gentoo-osx] Re: [RFC] Separate alt-prefix repo for base-system packages.

[Finn Thain]

On Tue, 30 Aug 2005, Brian Harring wrote:

> On Wed, Aug 31, 2005 at 01:32:04AM +1000, Finn Thain wrote:
>
> > My feeling is that the burden of managing the mappings is better than
> > the burden of managing one package.provided for mac os 10.3, alongside
> > another for 10.4, etc. (If I'm wrong about that, then this exercise is
> > pointless.)
> Actually, I agree; it's cleaner then just autoassuming stuff is there.

Thing is, if you undertake to track another package manager in this way, 
you must expect the worst from the vendor. So the question is, just how 
robust are such mappings are in the face of upstream mayhem?

Here are some scenarios, where I think the present package.provided method 
seems to work better,

1. Vendor changes package manager API.
   - user will have no vendor deps until devs update the shim

2. Vendor renames a package.
   - user will lose a vendor dep until devs add a new mapping

3. Vendor combines two packages.
   - see 2.

4. Vendor bumps a package version.
   - see 2.

And here are some scenarios where the proposed method of mapping & masking 
is better:

5. Vendor splits a package.
   - existing method loses if any part is no longer installed by default
   - new method works, given vendor bumps package version

6. Vendor drops a package entirely or renders it broken as a dep.
   - existing method loses. e.g. if this happened in mac os 10.3.9, all 
     10.3 users would have suffered
   - new method works, given vendor bumps package version

7. Vendor fixes a previously broken package
   - existing method loses. e.g. if this happened in mac os 10.3.9, no 
     10.3 users benefit, because many still do not have the fix
   - new method works, given vendor bumps package version

8. Vendor adds a package already in the tree.
   - old method loses if the two packages are not equivalent
   - new method wins if a virtual/metapackage can be used to mean "close 
     enough"

9. Vendor adds a package not already in the tree.
   - old method loses because deprecated profiles (e.g. mac os 10.2) will 
     never get the benefit of that package
   - new method wins because a new mapping is all that is required

As I described it, a mapping is a full mapping from vendor PV to portage 
PV. So a new mapping is needed when the vendor revs the package (point 4 
above).

Now, if we could also have an ebuild without a version number, like 
/opt/gentoo/usr/portage/vendor-apple/sys-devel/xcode/xcode.ebuild, it 
could just map a vendor name to a portage name. The synthetic vendor 
package that shows up in the vdb would get the vendor's full version. In 
this case, the devs' work is lessened because a new mapping wouldn't have 
to be added every time the vendor revs a package. Instead, package.mask 
would provide QA.

-f
-- 
gentoo-osx@g.o mailing list