Gentoo Archives: gentoo-osx

From: Finn Thain <fthain@××××××××××××××××.au>
To: gentoo-osx@l.g.o
Subject: Re: [gentoo-osx] Re: [RFC] Separate alt-prefix repo for base-system packages.
Date: Wed, 31 Aug 2005 04:17:22
Message-Id: Pine.LNX.4.63.0508311226590.17015@loopy.telegraphics.com.au
In Reply to: Re: [gentoo-osx] Re: [RFC] Separate alt-prefix repo for base-system packages. by Brian Harring
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