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
--
[email protected] mailing list
