On Tue, 1 Feb 2005, Hasan Khalil wrote:
...
We do not yet have policy for packages that are provided by Apple and that have a different API than that of the gnu version. I'm opening up the floor here for discussion on this.
Well, first, write the ebuild for the BSD version :-)
What comes immediately to mind is making the said packages a virtual, and then satisfying the virtual in our profile.
Yes. You just use the BSD one for a macos profile, and the GNU one for a linux profile.
I'm not completely serious about writing ebuilds for all of Apple's stuff we depend on. I wrote to this list with a rant about "vendor" packages a while back, to address exactly this problem. But, since OpenSolaris is out now, it seems a bit irrelevant.
This is probably just a naming convention issue, i.e. what do you call Apple's cpio, Sun's cpio, etc in order to add them to package.provided and thus satisfy the virtual.
It gets interesting because, someday, someone will write an ebuild for Darwin's cpio, and it will be the same as the OS X one. So, one might ask, what are they going to call their ebuild & category, and I'll just put that in package.provided.
This should work most of the time, as most packages that use, for example, zip, do not use any of the arguments that differ between the gnu and BSD versions.
Yep, in those cases, you change the dep to be the virtual, and save some time and space by using the already present (Apple) one.
The problem arises when a package really needs the GNU version -- you can't just specify that as a dep, since the GNU one will clobber the Apple one, and people will get terribly upset. Or will it? Doesn't pathspec permit both versions to be installed?
-f
-- gentoo-osx@gentoo.org mailing list
