From: Aron Griffis <agriffis@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Discussion: alternative compatible utilities
Date: Thu, 16 Jun 2005 22:32:26 -0400 [thread overview]
Message-ID: <20050617023226.GA11455@mustard.flatmonk> (raw)
In-Reply-To: <200506160757.19214@enterprise.flameeyes.is-a-geek.org>
[-- Attachment #1: Type: text/plain, Size: 3939 bytes --]
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
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-06-17 13:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-16 5:57 [gentoo-dev] Discussion: alternative compatible utilities Diego 'Flameeyes' Pettenò
2005-06-16 8:26 ` Luca Barbato
2005-06-16 11:18 ` Dan Meltzer
2005-06-17 2:32 ` Aron Griffis [this message]
2005-06-17 14:05 ` Diego 'Flameeyes' Pettenò
2005-06-18 11:23 ` Martin Schlemmer
2005-06-21 18:45 ` Aron Griffis
2005-07-05 10:37 ` Martin Schlemmer
2005-06-21 18:42 ` Aron Griffis
2005-06-21 18:57 ` Diego 'Flameeyes' Pettenò
2005-06-18 3:29 ` Grant Goodyear
-- strict thread matches above, loose matches on Subject: below --
2005-06-16 21:26 Alec Warner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050617023226.GA11455@mustard.flatmonk \
--to=agriffis@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox