Gentoo Archives: gentoo-osx

From: Finn Thain <fthain@××××××××××××××××.au>
To: gentoo-osx@l.g.o
Cc: Brian Harring <ferringb@g.o>
Subject: Re: [gentoo-osx] Re: [RFC] Separate alt-prefix repo for base-system packages.
Date: Tue, 30 Aug 2005 03:10:13
In Reply to: Re: [gentoo-osx] Re: [RFC] Separate alt-prefix repo for base-system packages. by Kito
> On Aug 29, 2005, at 5:30 AM, Finn Thain wrote: > > >I reckon XML is important, though perhaps not in the way you describe. > >As I see it, where ever portage is deployed as a secondary package > >manager, it needs to consult the primary one. That means that there > >needs to be a standard protocol for one package manager to query > >another.
(I should have mentioned, you don't really need XML for this, you can generate /etc/package.provided by a wrapper around emerge. Then you can mask untested stuff in it using a single ppc-macos profile and avoid the bogus package.provided files in all the present macos profiles.)
> I'm not sure I agree. I think this gets too close to a package.provided > situation, portage will never know enough about another systems packages > to map their functionality to its own. I think its preferable to let > portage handle what it knows first hand before trying to force it data > from a foreign host.
I'm not proposing that one "injects" non-identical packages under the same names. Actually, I have been against that since the beginning. I was thinking of something like, at run time, query the vendor package manager and use the result to populate the tree with packages like vendor-apple/sys-devel/xcode-1.5, vendor-sun/app-arch/cpio-x.y.z for example (please substitute sgi, bsd-ports, redhat or debian etc if you are hostile to any of my examples). Apple's XCode is closed source, and sun's cpio is now open. The former requires an ebuild to invoke installer(8), the latter requires an ebuild to build it from source. No-one is lying to portage here. And, if sys-apps/bsd-awk-x.y.z builds the same thing that apple ships, it can provide vendor-apple/sys-apps/bsd-awk. Also, the ebuilds for both vendor-apple/sys-apps/bsd-awk and sys-apps/bsd-awk should provide virtual/awk. So, when arbitrary ebuild foo wants generic awk (doesn't care about gnu extensions), it can depend on that virtual (unless virtuals are to be deprecated, in which case foo somehow has to depend on any vendor, including gentoo).
> >IMHO, this sounds like a "gentoo-darwin" sub-project to gentoo-alt, > >along-side os x and bsd. It isn't really a fork except in as much as > >the profile arrangement doesn't really accomodate work on darwin proper > >(but then the profile arrangemnet is flawed anyway: it only exists this > >way because of the package.provided crutch). > > I was looking at it more as a place to develop some new portage > features...Gentoo/Darwin has always been lurking, this is more in the > area of just getting offsets working.
OK, I see what you are getting at now. That was something that I failed to infer from the email you forwarded to the list. Most of what I said in reply isn't very relevant to that. Excepting that, if you can leverage existing packages, prefixed installs are much more useful -- having a complete set of deps installed on a prefix is not much better than a stage3 chroot with your home directory bind mounted below it. -f -- gentoo-osx@g.o mailing list