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