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

[Finn Thain]

On Wed, 9 Nov 2005, Nathan wrote:

> On 11/8/05, Finn Thain <fthain@××××××××××××××××.au> 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.
> > >
> > > Agreed 100%.
>
> Also agreed.  I'm all for maximum Gentoo-compatibility.  I would prefer
> all utils that Gentoo expects to be present, be installed and used by
> Gentoo in its own prefix, without any name changes.  The less
> Apple-specific modifications needed, the better.

It would be counter-productive to have two ebuilds for GNU make in the 
tree: one for Mac OS and one for Linux. On a progressive system, or a 
Gentoo Darwin system, or a prefixed OS X system, one kind of GNU make 
should be enough for interoperability, and so one ebuild should be enough 
to have correct deps. If some Apple-specific modifications are needed to 
achieve that, I don't see a problem.

If two ebuilds are required because of interoperabilty issues, then there 
is no Apple-specific modification. Just a name collision, which is what 
this thread is really about.

If this is about "Apple-specific modifications", did you consider all the 
"alt-specific" modifications caused by Linux calling GNU sed "sed", while 
-alt systems call it "gsed"? The irony is, I actually proposed uniformity.

>
> > 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.

That is not the primary aim. I'll try and explain it better. Here are 
three scenarios:

- prefix on foriegn distro
  (e.g. Debian, Fedora, upstream BSD, Sun Solaris GNU/Solaris, Apple Mac OS, 
  OpenDarwin, GNU/Darwin...)
- progressive on foreign distro
  (same examples)
- single package manager
  (e.g. Gentoo Darwin, Gentoo Solaris, Gentoo *BSD, Gentoo Linux)

Now, when you adopt the Gentoo/Alt (read Gentoo BSD) policy that says "In 
a Gentoo/ALT system profile, you can always find these tools ... gsed ... 
gmake ... gawk ... gpatch ... gdiff ... gfind ... gxargs", you encourage 
everyone to special case an alt system, and then use these names in their 
scripts instead of the Gentoo Linux names.

To support those scripts, any alt system now has to install the best part 
of a base system, with loads of "g"-prefixed binaries. On arbitrary 
progressive system, you assume that the vendor doesn't ship any similarly 
named binaries or you will still create a bunch of collisions. Yes, more 
collisions than you would have otherwise had, because the policy states 
that _all_ of these will be present, so more packages are needed.

Adding more packages on a prefixed system is bad news for different 
reasons. Imagine you are a sysadmin (I am) and you have hundreds of users 
that want to effectively do "emerge system" in their home directories, 
when they could just use the host tools instead! If I was one of those 
users, probably fast running out of quota, I'd start sending patches or 
reporting bugs to Gentoo.

> If you need to figure out which util is called by default in your shell
> session, try using 'which'.

I don't. Besides, while "which" is nice, "type" is more portable, 
particularly on csh systems like traditional BSD (and early OS X, BTW).

> 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.

Exactly. Only Gentoo stuff needs to have the symlinks 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"?

To avoid "alt specific" code, and to avoid policy that makes Gentoo less 
flexible.

-f

> 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.
>
> Kudos to Kito et al. for all the hard work so far.  It's exciting to
> hear the news about the prefix-patched portage progress. (how's that
> for alliteration?)
>
> ~ Nathan
>
>
-- 
gentoo-osx@g.o mailing list