On Sun, 6 Nov 2005, Grobian wrote:
> My opinion actually was to just let it be ~ppc-macos, since there are no > known problems with the OS provided find and xargs. When we have a > prefix, we can just install the normal GNU find and xargs (without g > prefix) and have maximum compatibility with the other arches on that > point. Yeah, but why? Just because of excessive policy, or because you found that Apple's xargs/find is inadequate? > > The best Alt project policy is to always use portable shell script in > > the tree. That is, avoid gnu extensions. That would help minimise the > > base system if nothing else. > > > > http://www.gentoo.org/proj/en/gentoo-alt/index.xml > > If you can do an easy change to just make it work on non GNU versions -- > something which Flameeyes has put a lot efforts in -- then I prefer to > simply do that. However, if problems or limitations (like OSX's sed for > instance) which are not easy to circumvent, then I'd opt for getting the > GNU version to avoid making it very complicated for everyone. Sure, but adding a dep or a system package shouldn't impose a special naming convention that is different to the upstream convention. IMHO, diverging from upstream ends up "complicated for everyone". > Question that remains is whether we can use the OS provided tools > without having to lie against portage, or limiting portage to 'upgrade' > (override) them with 'newer' (other?) versions when necessary. What is the lie you refer to? package.providing a pkg foo that fails to interoperate with the Apple foo? When this issue arises, you either need to make Gentoo foo mimic Apple foo when running on a darwin-based system (which won't always help, but it isn't lying) or else you need another ebuild that can build the apple foo. But the "lie" is not really relevant here. Your point about overriding/overwriting binaries is relevant. Thing is, if you have a desperate need for GNU find that you can't code around in a portable way (perhaps with python), then you need to install it either renamed or moved. I don't have any issue with that -- except that choosing to do that should be a per package, per distro decision. My issue is mainly with the policy. -f -- [email protected] mailing list
