All right guys, there are now a few packages out there that we need to
somehow put in package.provided, or otherwise provide for them in
portage. The catch is that many of these packages are not the (Gentoo
default) gnu version, but rather the BSD version. app-arch/zip comes to
mind, but there are others.
If the API for the package is consistent with the gnu version, by
Gentoo for Mac OS X policy, we put the package in package.provided with
a comparable version number/string.
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.
What comes immediately to mind is making the said packages a virtual,
and then satisfying the virtual in our profile. 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.
--
Hasan Khalil
Ebuild/Porting Co-Lead
Gentoo for Mac OS X
PGP Key: 0x707B8F18 on pgp.mit.edu
somehow put in package.provided, or otherwise provide for them in
portage. The catch is that many of these packages are not the (Gentoo
default) gnu version, but rather the BSD version. app-arch/zip comes to
mind, but there are others.
If the API for the package is consistent with the gnu version, by
Gentoo for Mac OS X policy, we put the package in package.provided with
a comparable version number/string.
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.
What comes immediately to mind is making the said packages a virtual,
and then satisfying the virtual in our profile. 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.
--
Hasan Khalil
Ebuild/Porting Co-Lead
Gentoo for Mac OS X
PGP Key: 0x707B8F18 on pgp.mit.edu