Re: [gentoo-dev] Discussion: alternative compatible utilities

[Martin Schlemmer]

Hi,

I am probably going to be top on the bsd camp's 'most hated list' after
this, but here goes ...

The more I think on Gentoo/<insert bsd flavour here>, the more I tend to
get this picture of a little boy that wants to play with the older boys,
but are constantly in tears, as the older boys runs too fast for him, or
go places he cannot go.

Ok, so its not a perfect visualisation, but sort of gets the point
across.  Especially in one camp, many of the userland utilities is
really substandard (not even talking about supporting the extended
features most of us are accustomed to), but the once or twice I asked
why not replace it with the gnu versions, I got the answer: *sob*,
because we want to use our own *sob*.

This might have changed (the substandard quality), but I am sure the
need for these guys to use their own utilities have not.  Now, this is
all dandy and stuff, but I really do not see how this have to influence
90% (if not more) of the rest of Gentoo-land.


On Fri, 2005-06-17 at 16:05 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Friday 17 June 2005 04:32, Aron Griffis wrote:
> > Before working on a solution to the problem, could we get a more
> > complete list of the tools in question?  This has come up before but
> > the list seems to always end with "etc etc" ;-)
> Because I don't really know how many applications are available in different
> flavours.. so that's why we can use eselect so that it can be adapted "on the
> fly".
>

And I really do not see why for 10% (I am being generous) of users we
should make it possible to select which version of find (or whatever)
should be called by default.  What other version should the majority of
us select between anyhow?  Install the bsd versions as well??

I really do not see why we should add extra symlinks and extra logic for
90%+ users that will just never use it.

> > Unless I misunderstand you, I don't like this at all.  It means that
> > when an ebuild calls "grep" it doesn't have any idea what the
> > supported flags are.
> Well about grep we have no misunderstanding... grep is GNU grep also on the
> BSD. And actually it has no idea currently about that on G/FBSD or G/OSX.. we
> condition this using aliases, but the long-term goal is to avoid this.
>

Great, so just use a 'long term idea that is more bsd specific'.

> > So far we've been free to exploit GNU extensions (aka
> > reasonable functionality) in ebuilds.  I'd hate to see that go away.
> Never said it must go away, actually there's no way that it can go away
> completely but.. .we can ask *explicitely* for GNU tools in those cases
> (using gsed instead of sed just as an example, or gfind instead of find).
>

So now we have to start replacing all 'might not work on some sed's (or
whatever)' with gsed?  This really brings the sed-4 transition days with
all its gory details back to mind.

> > What scripts are you thinking of in this statement?  Sometimes
> > ./configure checks, not always, and AFAIK most other scripts don't
> > check.
> Most of them checks for GNU tools when they need them, for example there are a
> few ./configure which, knowing they need GNU make, in a system where make is
> BSD and gmake is GNU, launching "make" then exec gmake to do the actual work.
>

I thought make already installs as 'gmake' on bsd systems ??

> > See, it's this "sed stuff is as compatible as possible" thing I don't
> > like.  You're talking about writing to a standard instead of an
> > implementation.  That works for a couple of well-defined compiled
> > languages, but I don't think it's going to work for shell scripting
> > (ebuilds), especially when the reality is that we'd be writing to half
> > a dozen different implementations instead of a standard at all...
> See above: when we need GNU sed, we can use gsed.
>

I might have here (and above) the wrong impression, but I do not think
using 'gsed' in ebuilds is the way to go.  Just do something bsd
specific that always have 'gsed' as 'sed' when emerge is running ??  See
below.

>
> > I don't think that switching to g-prefixed commands for GNU utilities
> > is a good answer.  We aren't going to be able to push that upstream,
> > which means maintaining a lot of patches ourselves.
> Upstream usually already have this fixed for BSD system for example. I haven't
> had too much trouble with that before on G/FBSD, for example the only
> autotool-created makefile which failed on BSD make was gawk, and that just
> because it used $(RM) var directly; most ./configure scripts checks for rm
> and creates $(RM) var themselves when make != gmake.
>

But I am assuming you cannot count on this, and this is why you want
this 'eselect abomination' ?  See below.

> > What you're suggesting would cause a lot of pain for the majority of
> > Gentoo develpers, i.e. the ones running GNU/Linux.
> As we are now, on G/FBSD we have anyway quite all the GNU utilities (but for
> example we don't need tar and about find we can use the BSD's one with
> ebuilds.
>
> Anyway, as I already had done, I'm here to fix in case something is using the
> wrong way... after a couple of examples this can be quite simple as for the
> old gnu-find dependent ebuilds which are now fixed.
>

But the problem is going to be that somebody will have to keep on
'policing' the ebuilds, and possibly teaching all devs all possible
variations (broken or not) out there?

The bit that Aron said about having things installed in a different
location that you snipped, might be your answer.

I don't think anybody (or too many) is going to moan too much about
having some things install with a 'g' prefix on bsd systems, but I for
one are going to complain about implementing something global such as
eselect for utilities that have on 90%+ of the installations just the
one implementation.

I know that say installing all bsdish tools in say /usr/ucb, might not
fly, as some of the bsd implementations might not be able to relocate
those.

You might however say install all gnuish tools with the 'g' prefix, and
then install wrapper scripts/stubs into say /usr/bin/gnu/ or /bin/gnu/
(with /usr/bin/gnu/find calling gfind, etc), and portage just adds this
path as the first path to $PATH ...

This should cover the fact that aliases might not work in all cases, and
is bsd specific implementation.


Thanks,

-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa