Diego 'Flameeyes' Pettenò wrote:[Thu Jun 16 2005, 01:57:14AM EDT] > Let me explain: on Gentoo/Linux systems, all the base utilities > (make, tar, sed, etc etc) are GNUish
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" ;-)
> This limits a bit the user because to use other kind of utilities it
> must use aliases and he can't change, for example, the tar used by
> portage or by other scripts.
>
> As eselect's work is proceeding it can be interesting having a way
> to have the base utils install with a prefix (g for GNU stuff, bsd
> for BSD stuff, eventually fbsd/obsd/nbsd if they are different) and
> then having a link to the basename which acn be changed with
> eselect.
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. Writing shell scripts to the lowest common
denominator is incredibly painful; just ask the maintainer of
keychain. So far we've been free to exploit GNU extensions (aka
reasonable functionality) in ebuilds. I'd hate to see that go away.
Personally I'd prefer to see the selection continue to happen at the
user level (via alias or PATH) rather than happening at the system
level via eselect. I'm all for eselect, but not for programmatic
interfaces that only nominally resemble each other.
Btw, this has been "solved" in the commercial UNIXes for SysV versus
BSD utils for a long time. Most of the time SysV utils are installed
in /usr/bin and the BSD utils are installed in /usr/ucb. I'm not
saying we have to follow that pattern exactly, but I like the fact
that /usr/bin/grep is always the same thing (on a given UNIX)
> Most of the scripts which needs a specific syntax (usually GNU
> syntax) already checks for prefixed executables like gmake, gsed and
> so on,
What scripts are you thinking of in this statement? Sometimes
./configure checks, not always, and AFAIK most other scripts don't
check.
> but the main problem is with portage (think of all the make
> DESTDIR="${D} install stuff), also if emake is fixed and sed stuff
> is as compatible as possible.
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...
> Having to provide compatibility with such a framework is quite
> difficult at this point because many ebuilds does depend on GNU
> syntax also if not clearly stated, but I hope this can be fixed
> step-by-step using g-prefixed commands (after making sure that all
> systems will have g-prefixed commands). It's not like something is
> going to happen soon, but maybe in the future this can be a good way
> to make sure we expand the abiliy of users to select what they
> really want.
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. Within our own
developer body, we're going to have an impossible task keeping things
compatible since few people have the knowledge required to write
truly cross-platform scripts.
I know this isn't offering an easy answer for the BSD folks. :-(
What you're suggesting would cause a lot of pain for the majority of
Gentoo develpers, i.e. the ones running GNU/Linux. Let's think it
through very carefully so we understand our options before setting
down this path.
Regards,
Aron
--
Aron Griffis
Gentoo Linux Developer
pgpBd6FuDmvwa.pgp
Description: PGP signature
