Re: [gentoo-osx] Re: sys-apps/findutils (GNU)

[Grobian]

Nathan wrote:
>> Doesn't that mean that new code that comes to depend on the gfind and
>> gxargs usage will also have to be changed at that later date? If you avoid
>> this policy now, you avoid that problem later. No-one has yet come up with
>> an inadequacy of BSD xargs and find, so why do it? Just for the sake of a
>> misguided policy?
>
> A lack of examples on your part does not a misguided policy make.
> Have you ever used both BSD and GNU utils extensively?  Even something
> as simple as 'ls' doesn't have the same behaviour and flags between
> them, not to mention that each version can have changes introduced
> upstream without warning.  What do you have to gain from using a BSD
> util?  Saving 100KB in disk space?  There's a lot to gain by
> installing what Gentoo expects: it may actually work.
>
> As for xargs specifically, take a peek at the synopsis from the BSD &
> Gentoo man pages:
>
> (BSD/OS X) xargs SYNOPSIS
>      xargs [-0pt] [-E eofstr] [-I replstr [-R replacements]] [-J replstr]
>            [-L number] [-n number [-x]] [-s size] [utility [argument ...]]
>
> (Gentoo) xargs SYNOPSIS
>        xargs  [-0prtx]  [-e[eof-str]]  [-i[replace-str]]
> [-l[max-lines]] [-n max-args] [-s
>        max-chars]  [-P  max-procs]  [--null]  [--eof[=eof-str]]
> [--replace[=replace-str]]
>        [--max-lines[=max-lines]]    [--interactive]
> [--max-chars=max-chars]   [--verbose]
>        [--exit] [--max-procs=max-procs] [--max-args=max-args]
> [--no-run-if-empty]  [--ver-
>        sion] [--help] [command [initial-arguments]]
>
> See any potential problems?

The real problem is -E/-e in this example or when flags don't do exactly 
the same.  Additions by GNU don't have to be a problem.

>> But, it seems to me that there is a good compromise, along the lines of
>> Diego's eselect proposal (similar to Debian's /etc/alternatives). We could
>> use eselect or similar to maintain a "symlink farm" of g-prefixed symlinks
>> to the GNU binaries. A baselayout revision could safely permit a
>> Gentoo-wide policy whereby such gfoo binaries could be called from any
>> boot script, tool script etc. In this way, you can avoid having to special
>> case the distro in ebuilds and scripts, and you can avoid pulling in
>> redundant deps on systems that ship the same binaries without g-prefixes.
>> On those systems, the vendor package could just be "eselected" to create
>> the symlinks, and indeed the baselayout for such systems could ship with
>> the symlinks already in place.
>
> Assuming I understand your point correctly (which is debatable), that
> is an awfully complicated solution whose primary aim seems to ensure
> that you don't confuse /some/prefix/bin/someutil with
> /usr/bin/someutil by turning one into a symlink to the other.  If you
> need to figure out which util is called by default in your shell
> session, try using 'which'.  If you need to _ensure_ that you use OS X
> utils while in a shell, a simpler solution would be to not put the
> gentoo directories in $PATH in the first place.

eselect is a nice idea, but only useful for the user.  Portage will 
always prefer to use it's 'own' tools, IMHO.  If a user wants to use 
OSX/xargs instead of GNU/xargs, that user should fiddle with his/her 
path, don't source the Gentoo prefix script or place a symlink to 
OSX/xargs in his/her ~/bin (and make that one come first in the path).

>> That is the only way I can see for compatibility both with the variety of
>> Darwin distros, and with the variety of Gentoo OS's.
>
> Why would Gentoo need to stay compatible with "Darwin distros"?  OS X
> isn't going anywhere if you install Gentoo in a prefix.  The whole
> idea is to have a Gentoo package manager installing Gentoo stuff in
> it's own little corner of the filesystem.  We DO want to keep
> gentoo-osx as compatible as possible with all the __other gentoo
> arch's__ so that we can leverage all the good work being done for
> those arches.

I think that the first target will be to have maximum compatability with 
other Gentoo projects, then we can examine which tools we can use from 
the OS without causing trouble (to minimise the install).  I'd like to 
get it functionally working first.  I don't think we kill an alternative 
path by doing so.


-- 
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
-- 
gentoo-osx@g.o mailing list