Mailing List Archive

Grobian wrote:
> I thought let's give it a shout, because maybe we should add it to the
> base profile somehow and alias some more to have calls to find and xarg
> (when not in a pipe) being directed to gfind and gxargs for maximum
> compatibility. Maybe it's not worth it. Opinions?

How big is the installation of findutils? If it's not gigantic (I don't
expect it to be) then I think this is a good idea. Keeping things
within the portage environment as similar to "mainline" as possible will
only avoid hassles. This, however does not encourage portage itself to
become more cross-platform, conforming the new hosts to portage.

Other thoughts?

--
Nick Dimiduk
Gentoo Developer
ndimiduk (at) gentoo (dot) org
--
gentoo-osx@gentoo.org mailing list

On Sat, 5 Nov 2005, Nick Dimiduk wrote:

> Grobian wrote:
> > I thought let's give it a shout, because maybe we should add it to the
> > base profile somehow and alias some more to have calls to find and
> > xarg (when not in a pipe) being directed to gfind and gxargs for
> > maximum compatibility. Maybe it's not worth it. Opinions?
>
> How big is the installation of findutils? If it's not gigantic (I don't
> expect it to be) then I think this is a good idea. Keeping things
> within the portage environment as similar to "mainline" as possible will
> only avoid hassles.

If by "mainline", you mean "Gentoo/Linux", the major dis-similarity
remaining is the name of the executable.

IMHO, the Alt project policy of mandatory "g" prefixes is misguided. If it
suits BSD, great, but AFAICT it limits portability to non Gentoo systems,
and it shouldn't be applied to all -alt projects.

The majority of potential small prefix installations need that
portability. I don't know about you, but under limited quota, as an
unprivileged user, I don't want to have to do a large "emerge system" in
my work/college/uni/client's home directory).

http://www.gentoo.org/proj/en/gentoo-alt/maintnotes.xml

So, the best policy is to follow the upstream convention. So, if Apple
calls gmake "make", then Gentoo/OS X should do likewise. The idea being
that this works on OS X (in a prefix), Gentoo/Darwin, Gentoo/OS X,
OpenDarwin (in a prefix) etc -- basically any CHOST = *-*-darwin* system.

> This, however does not encourage portage itself to become more
> cross-platform, conforming the new hosts to portage.
>
> Other thoughts?

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

-f


--
gentoo-osx@gentoo.org mailing list

Finn Thain wrote:
> On Sat, 5 Nov 2005, Nick Dimiduk wrote:
>
>> Grobian wrote:
>>> I thought let's give it a shout, because maybe we should add it to the
>>> base profile somehow and alias some more to have calls to find and
>>> xarg (when not in a pipe) being directed to gfind and gxargs for
>>> maximum compatibility. Maybe it's not worth it. Opinions?
>> How big is the installation of findutils? If it's not gigantic (I don't
>> expect it to be) then I think this is a good idea. Keeping things
>> within the portage environment as similar to "mainline" as possible will
>> only avoid hassles.
>
> If by "mainline", you mean "Gentoo/Linux", the major dis-similarity
> remaining is the name of the executable.
>
> IMHO, the Alt project policy of mandatory "g" prefixes is misguided. If it
> suits BSD, great, but AFAICT it limits portability to non Gentoo systems,
> and it shouldn't be applied to all -alt projects.

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.

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

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.


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

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
--
gentoo-osx@gentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

- --Lina Pezzella
Gentoo Developer



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFDcWceNJ9STR9DbYERAiiVAKCCAUl5Q1LgwgTPQ72FTdODoWUTqACdHxiC
y+kg0W3Szfo60cbe+hENgws=
=FuVB
-----END PGP SIGNATURE-----
--
gentoo-osx@gentoo.org mailing list

On Tue, 8 Nov 2005, Lina Pezzella wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> >
> >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%.

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?

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.

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.

-f

> - --Lina Pezzella
> Gentoo Developer
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (Darwin)
>
> iD8DBQFDcWceNJ9STR9DbYERAiiVAKCCAUl5Q1LgwgTPQ72FTdODoWUTqACdHxiC
> y+kg0W3Szfo60cbe+hENgws=
> =FuVB
> -----END PGP SIGNATURE-----
>
--
gentoo-osx@gentoo.org mailing list

On 11/8/05, Finn Thain <fthain@telegraphics.com.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.

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

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

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

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@gentoo.org mailing list

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@gentoo.org mailing list

On Sunday 06 November 2005 21:10, 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.
I think you shouldn't install it non-prefixed.
Reasoning? You change the expected environment for also Portage, that
currently uses GNU userland to identify find and xargs commandline.

The tree is already safe for find and xargs syntax, and there are no big deal
in using GNU's or BSD's find and xargs to ebuilds.
There are for users, tho, but letting them use GNU find without knowing is,
IMHO, an error.
Allowing an user to select gfind explicitely is another story.

For what it's worth, the userland-gnu ebuild installs /usr/libexec/gnu links
for GNU tools, also cp, mv, make, find and so on. Putting that in $PATH
allows users to have interactive shells using GNU userland without having to
do hacks around.


Remember that compatibility is *not* only with Gentoo Linux, we should try to
minimize the difference between Gentoo/ALT projects, too.
If you start shipping in prefixes the GNU tools, people would start telling
other Gentoo/ALT ports to do so, and I for one don't want that, as I'd rather
see Gentoo/*BSD ports to use their own userland where applicable.
For design decisions, such as "should we use the default or not", gentoo-alt
is the place, don't take one-sided decisions or you'll repeat the errors for
which many devs blames the Gentoo for Mac OSX project and Gentoo/ALT project
entirely.

--
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

On Wed, 9 Nov 2005, Nathan wrote:

> On 11/8/05, Finn Thain <fthain@telegraphics.com.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@gentoo.org mailing list

On Thu, 10 Nov 2005, Grobian wrote:

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

Yes, eselect is not really neede. I don't expect the user to need to move
symlinks around too often.

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

The g-prefixed symlinks aren't there for the users' benefit, they create a
uniform environment for gentoo scripts and ebuilds regardless of distro.

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

The point is that the policy shouldn't encourage the use of names that
aren't needed. Also, the policy shouldn't encourage the use of g-prefixes
at all before there is agreement on a plan to provide them in a way that
is sufficiently flexible -- otherwise, -alt will only get blamed for more
ugly distro specific special cases.

-f
--
gentoo-osx@gentoo.org mailing list

Finn Thain wrote:
> 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.

Now I see your complaint. I didn't see that when skimming the website.
In my early days in the project I once suggested to use a special
directory with symlinks like "sed -> /usr/bin/gsed" (where gsed was only
to avoid collision) and have that directory first in the path by setting
it in profile.bashrc. This idea would solve the `find . | xargs`
problem, but was rejected because it was considered to be a dirty hack,
aliases worked fine for most cases too, and of course the work of
Flameeyes to just get people using the right (non-GNU) syntax. The
extra directory with symlinks would just be a sort of simulated prefix
situation. No biggy, but I'd still prefer it over aliasing sed to gsed.

For the policy; I think we should have a discussion on these g-prefixed
variants. Personally, I think they suck, just because of their name.
Sun has shown with Solaris that you can use directories to have multiple
versions/editions of the same programs. (Only on Solaris it's a bit
confusing sometimes...)

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

Well... as user you have the strange thing to always dislike the OS
provided stuff, just because (random rant) "everything on Fedora sucks!".

Back to your (IMHO) valid comment: yes, it would be great if it would be
possible to only install xfig-3.2.5 using portage, just as it works on
OSX right now, without having to emerge a compiler and loads of depends
first.
Question for me there is, do we have to priorise there? I am a user at
work, and I have a nice workstation, with a homedir being backupped, and
a lot of scratch on my local workstation. I won't miss a gig or 2 there.
It would always be possible for -alt to provide a pre-filled
package.provided for some known OS distributions that users can apply
themselves to get the behaviour as we now have on OSX.
An alternative (much more interesting) would be if portage could 'ask'
the host OS through some interfacing script/program if a certain program
is 'provided' and which version. In a RPM world something like `rpm -q
etc.` while on OSX perhaps only package.provided would suffice. Who
knows. I guess that this option would require portage to be extended
somewhat.

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

...or binaries...


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

Diego 'Flameeyes' Pettenò wrote:
> On Sunday 06 November 2005 21:10, 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.
> I think you shouldn't install it non-prefixed.
> Reasoning? You change the expected environment for also Portage, that
> currently uses GNU userland to identify find and xargs commandline.

I agree with you, but I don't follow your reasoning. Portage IMHO
expects it's own (GNU) find and xargs. Or well, not Portage, but devs
that just create ebuilds on Gentoo Linux and don't mind about your bugs
for sticking to a common subset of supported flags.

> The tree is already safe for find and xargs syntax, and there are no big deal
> in using GNU's or BSD's find and xargs to ebuilds.
> There are for users, tho, but letting them use GNU find without knowing is,
> IMHO, an error.
> Allowing an user to select gfind explicitely is another story.

Which would be the case if we would include it in the base install.
Since we don't override anything, we simply add it as g*. The alias sed
-> gsed is only used in Portage itself, it's *not* set in the global
profile for the user.

> For what it's worth, the userland-gnu ebuild installs /usr/libexec/gnu links
> for GNU tools, also cp, mv, make, find and so on. Putting that in $PATH
> allows users to have interactive shells using GNU userland without having to
> do hacks around.

Which is nice. Why don't we (OSX) use this ebuild? (If it indeed does
what I think it does.)

> Remember that compatibility is *not* only with Gentoo Linux, we should try to
> minimize the difference between Gentoo/ALT projects, too.

This is currently being made somewhat different because there are three
flavours of Gentoo Alt systems. Maybe you and I should have a chat on
outlining this.

> If you start shipping in prefixes the GNU tools, people would start telling
> other Gentoo/ALT ports to do so, and I for one don't want that, as I'd rather
> see Gentoo/*BSD ports to use their own userland where applicable.
> For design decisions, such as "should we use the default or not", gentoo-alt
> is the place, don't take one-sided decisions or you'll repeat the errors for
> which many devs blames the Gentoo for Mac OSX project and Gentoo/ALT project
> entirely.

Then this rather innocent email I started this thread with, turns out to
be a the cause of a valuable conclusion, that you and I need to do some
work on this subject.


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

On Thursday 10 November 2005 18:19, Grobian wrote:
> I agree with you, but I don't follow your reasoning. Portage IMHO
> expects it's own (GNU) find and xargs. Or well, not Portage, but devs
> that just create ebuilds on Gentoo Linux and don't mind about your bugs
> for sticking to a common subset of supported flags.
No, people got already stabbed for using GNU find options in ebuilds, as they
are not portable and IIRC this was already clear a lot of time ago.
And for the rest, give me the ones who don't care about my bugs, and I'll see
with their herd/project/whatever will be.

> The alias sed
> -> gsed is only used in Portage itself, it's *not* set in the global
> profile for the user.
Right

> Which is nice. Why don't we (OSX) use this ebuild? (If it indeed does
> what I think it does.)
Because it's not in main tree? Remember when I said you should start looking
at the gentoo-alt overlay?

> Then this rather innocent email I started this thread with, turns out to
> be a the cause of a valuable conclusion, that you and I need to do some
> work on this subject.
Right.

--
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

Diego 'Flameeyes' Pettenò wrote:
> On Thursday 10 November 2005 18:19, Grobian wrote:
>> I agree with you, but I don't follow your reasoning. Portage IMHO
>> expects it's own (GNU) find and xargs. Or well, not Portage, but devs
>> that just create ebuilds on Gentoo Linux and don't mind about your bugs
>> for sticking to a common subset of supported flags.
> No, people got already stabbed for using GNU find options in ebuilds, as they
> are not portable and IIRC this was already clear a lot of time ago.
> And for the rest, give me the ones who don't care about my bugs, and I'll see
> with their herd/project/whatever will be.

Well, I guess that was a misconception of mine then, and it's obvious
how things stick together here. There is no reason whatsoever to use
(GNU) find and xargs on OSX (as with any OS that has find or xargs that
supports the subset of commands you defined to be sufficient).

I think we can make it an official statement, that as soon as a certain
application doesn't meet this requirement of the defined minimal
functionality (like OSX's sed?) that it should be replaced with another
one, usually done through portage as it is the simplest.
TODO: define the minimal requirements.

>> Which is nice. Why don't we (OSX) use this ebuild? (If it indeed does
>> what I think it does.)
> Because it's not in main tree? Remember when I said you should start looking
> at the gentoo-alt overlay?

Right... hit me. I got it checked out... maybe I don't get checkin
messages from it?


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

On Thursday 10 November 2005 20:34, Grobian wrote:
> Right... hit me.  I got it checked out... maybe I don't get checkin
> messages from it?
It's there since a bit of time, it was imported from old CVS, I blogged about
userland-gnu this summer :)

--
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE