[gentoo-dev] Discussion: alternative compatible utilities

[gentoo-dev] Discussion: alternative compatible utilities

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 2090 bytes --]

As Gentoo/FreeBSD proceeds, I'm trying to abstract as much as I can the 
underlying userland.
Thinking of Gentoo/FreeBSD just as a starting point for other porting of 
Gentoo's framework on different operating systems (for example the 
already-work-in-progress Gentoo/Darwin, the I-don't-know-how's-doing 
Gentoo/OpenBSD, and the maybe-someone-will-work-on Gentoo/NetBSD), there's 
something I'd really like to see: alternatives for system utilities.

Let me explain: on Gentoo/Linux systems, all the base utilities (make, tar, 
sed, etc etc) are GNUish; on Gentoo/FreeBSD they are BSDish; on Gentoo/Darwin 
I don't really know :P
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.
Most of the scripts which needs a specific syntax (usually GNU syntax) already 
checks for prefixed executables like gmake, gsed and so on, 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.

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.

Comments, ideas, and everythign else is welcome, it's a discussion after all.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)

http://dev.gentoo.org/~flameeyes/


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Luca Barbato]

Diego 'Flameeyes' Pettenò wrote:

> Let me explain: on Gentoo/Linux systems, all the base utilities (make, tar, 
> sed, etc etc) are GNUish; on Gentoo/FreeBSD they are BSDish; on Gentoo/Darwin 
> I don't really know :P
> 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.
> 

Surely it would be interesting for developer that want to make sure
their code will build in other userspaces w/out switching os,
and if that won't be so painful, would worth testing it.

Obviously having it now isn't really needed. Thinking about that when
committing/updating ebuild would be good.

( still I do hate bsd core utils implementations but that is just my
opinion =) )

lu

-- 

Luca Barbato

Gentoo/linux Developer		Gentoo/PPC Operational Leader
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

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

[Dan Meltzer]

Well it would be nice to have it all abstracted, wouldn't stablizing a
package get exponetially harder? Not only would each arch need to be
tested, each combination of packages on each arch would need to be
tested, if FEX openpam became usable on linux instead of just
linuxpam, each arch that stableized would now need to say works for
this arch for linuxpam, and works for this arch for openpam, which
would cause lots and lots of keywords mess.

Or am I misunderstanding your post?

On 6/16/05, Luca Barbato <lu_zero@gentoo.org> wrote:
> Diego 'Flameeyes' Pettenò wrote:
> 
> > Let me explain: on Gentoo/Linux systems, all the base utilities (make, tar,
> > sed, etc etc) are GNUish; on Gentoo/FreeBSD they are BSDish; on Gentoo/Darwin
> > I don't really know :P
> > 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.
> >
> 
> Surely it would be interesting for developer that want to make sure
> their code will build in other userspaces w/out switching os,
> and if that won't be so painful, would worth testing it.
> 
> Obviously having it now isn't really needed. Thinking about that when
> committing/updating ebuild would be good.
> 
> ( still I do hate bsd core utils implementations but that is just my
> opinion =) )
> 
> lu
> 
> --
> 
> Luca Barbato
> 
> Gentoo/linux Developer          Gentoo/PPC Operational Leader
> http://dev.gentoo.org/~lu_zero
> 
> --
> gentoo-dev@gentoo.org mailing list
> 
>

-- 
gentoo-dev@gentoo.org mailing list

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

[Aron Griffis]

[-- 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 --]

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

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 3227 bytes --]

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

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

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

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

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

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

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 6582 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

Azarah wrote:[Sat Jun 18 2005, 07:23:19AM EDT]
> 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.

That would actually cause a lot of problems because the PATH would be
inherited by configure and/or make.  The result is that programs get
GNU tools when they are built, but BSD tools at run-time.  I can only
imagine that causing a lot of confusion.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]

On Tue, 2005-06-21 at 14:45 -0400, Aron Griffis wrote:
> Azarah wrote:[Sat Jun 18 2005, 07:23:19AM EDT]
> > 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.
> 
> That would actually cause a lot of problems because the PATH would be
> inherited by configure and/or make.  The result is that programs get
> GNU tools when they are built, but BSD tools at run-time.  I can only
> imagine that causing a lot of confusion.
> 

Ahh, right - didn't think about that.  Although you realise that the
same issues will be present when eselecting something before and after
emerge ?


Thanks,

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 3589 bytes --]

Diego 'Flameeyes' Pettenò wrote:[Fri Jun 17 2005, 10:05:32AM EDT]
> 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".

I'm not against using eselect to choose between applications, if that
is the right answer.  I'm against getting started on these changes
without having a better idea of the scope and impact of the project.
In other words, I think you need to do some work in an overlay so that
you can present a real list of affected ebuilds and utilites, rather
than stating that you "don't really know"

I appreciate that you brought this idea to the list early, before you
had done full investigation.  I do not want to discourage you.  Rather
I want to suggest the next step is a more complete investigation,
rather than committing any changes to the portage tree.  One of the
problems we've had with ports in general is that changes are committed
in a flurry of activity before careful consideration of the possible
alternatives.

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

Why is that a long-term goal?  What are the advantages/disadvantages
of the eselect method compared to the aliases?

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

*nod*

It's true that the autotools generally work with make programs other
than GNU make.  I ported Gnome (versions 1.2 and 1.4) to Tru64 once
upon a time and used the system-installed make (and compiler) for most
of it.

I still think it would be nice to have a list of things that will need
modification to work with your scheme.  Again, this is something that
could be culled from an overlay from which you've done a bootstrap and
install of a fairly comprehensive system.

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

As Az mentioned, this is really going to be annoying unless all the
sed programs available support -i

I'll re-iterate: I'm not trying to shoot down this idea completely.
I just want to have a general understanding that it's the *right*
option before making treewide changes.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1611 bytes --]

On Tuesday 21 June 2005 20:42, Aron Griffis wrote:
> In other words, I think you need to do some work in an overlay so that
> you can present a real list of affected ebuilds and utilites, rather
> than stating that you "don't really know"
Well this was just a discussion, no work should really start for now :)

> Rather
> I want to suggest the next step is a more complete investigation,
> rather than committing any changes to the portage tree.
That was for sure :) No big change to do before something working is already 
there.. like we're doing for G/FBSD.

> Why is that a long-term goal?  What are the advantages/disadvantages
> of the eselect method compared to the aliases?
Because aliases makes difficult to follow the flow of an ebuild because you 
read "sed" and but is gsed that's called.. similarly for other tools.
Aliases are like #defines into C code.. makes debug harder, very harder.

> As Az mentioned, this is really going to be annoying unless all the
> sed programs available support -i
BSD does, and I think we can make a prerequisite to be used in portage that 
the system's sed supports -i.
The only problem is with the options orders.. sed -i -e expr works, sed -e -i 
expr or sed -e expr -i doesn't.

> I'll re-iterate: I'm not trying to shoot down this idea completely.
> I just want to have a general understanding that it's the *right*
> option before making treewide changes.
That's why we're discussing it :)

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Grant Goodyear]

[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]

Aron Griffis wrote: [Thu Jun 16 2005, 09:32:26PM CDT]
> 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.

The current situation is that portage sets aliases for tar, make, sed,
etcetera that point to the appropriate g* commands on the *BSD systems.
I have to admit that I'm actually quite content with that system, since
it's not at all intrusive to the Linux folks, and it's minimally
intrusive for the *BSDs.  It does require that all Gentoo systems have a
certain set of GNU utilities, but I'm quite willing to live with that
requirement.

All that said, if I'm completely missing the point please feel free to
tell me.

-g2boojum-
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Alec Warner]

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

Don't attempt to ignore the complexity because it sucks and gives you a
headache.  The complexity of multiple kernels, userlands, arches and
platforms exists whether you like it or not.  The key being the
management of the complexity.  Currently the tools perform poorly
because it's been primarly GNU userland + Linux kernel + random arches.
 The first two are easy to take care of and the third has arch teams.
Thus we probably need more keywords ( x86-fbsd-bsd...etc it's been said
before ) and we need more people to keyword stuff ( arch-kernel-userland
).  I think the big issue is to adapt to the new requirements without
making the current tools an overpatched mess.

Part of the issue I see is everyone is only focused on their little
problem.  X, Y or Z that I need is broken and I need fix foo; it's
talked about on IRC, it seems to work, it's implemented.  Then a week
later someone who wasn't on at time of discussion notes that it broke
something and and now needs to be 'fixed'.  I think Flameeyes has done
a pretty good job keeping everyone informed of Gentoo/fbsd's needs and
offering pretty good solutions on how to fix them in a general way.  I
think part of the problem is that this doesn't happen often enough and
we end up with a bunch of hacks that need to be integrated together.
- -Alec Warner
Ajec

Dan Meltzer wrote:

>Well it would be nice to have it all abstracted, wouldn't stablizing a
>package get exponetially harder? Not only would each arch need to be
>tested, each combination of packages on each arch would need to be
>tested, if FEX openpam became usable on linux instead of just
>linuxpam, each arch that stableized would now need to say works for
>this arch for linuxpam, and works for this arch for openpam, which
>would cause lots and lots of keywords mess.
>
>Or am I misunderstanding your post?
>
>On 6/16/05, Luca Barbato <lu_zero@gentoo.org> wrote:
>
>
>>Diego 'Flameeyes' Pettenò wrote:
>>
>>
>>
>>>Let me explain: on Gentoo/Linux systems, all the base utilities
(make, tar,
>>>sed, etc etc) are GNUish; on Gentoo/FreeBSD they are BSDish; on
Gentoo/Darwin
>>>I don't really know :P
>>>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.
>>>
>>>
>>>
>>Surely it would be interesting for developer that want to make sure
>>their code will build in other userspaces w/out switching os,
>>and if that won't be so painful, would worth testing it.
>>
>>Obviously having it now isn't really needed. Thinking about that when
>>committing/updating ebuild would be good.
>>
>>( still I do hate bsd core utils implementations but that is just my
>>opinion =) )
>>
>>lu
>>
>>--
>>
>>Luca Barbato
>>
>>Gentoo/linux Developer          Gentoo/PPC Operational Leader
>>http://dev.gentoo.org/~lu_zero
>>
>>--
>>gentoo-dev@gentoo.org mailing list
>>
>>
>>
>>
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQrHuf2zglR5RwbyYAQKz7g//ei85Mupvhm/nLq5FH3re1pKpYhmvREyX
bM51xqH4SXNWB1wCrVgHJXs7YV4nTLnl9lpvg+YKElcrCKwc4wqGTdvYWen9L/Is
IzmgHzKkkinfrDHQAXLylCy753S/fuiJowSAcg6rW+8sPadJHU3zYjunC4mhXLLL
99drUDDihS+8KljclJgVkP+fPFMqBo4GgtZtwHH/wksbeomWIIrlF90JFO1AZuA+
2kLrFcriPxe0/9UD4yZYEjgQ649cA3pYDCMoiNtmVLLeIBqvR7qdNP6LnRjhHD/5
d+f6SVADql2zreUZSxxnCTLN+V32ImRE9Mm6zAafQ/B4C+4uxGUkwQYNpPLrWZfd
TmMbd0qHFjmZVTSjwhk6L1lWvcro7Bp9o1IUTQzaqUcpcF/zhsgB9Av29svnhJgY
oqA9IavcoM6fT+gl1zSaiKoVCdGEGIAIxlwN/ePst5/hmf/AXr76ooAamAcJlKMV
Nrb7Q8crdd7usz4QIuNvjcw/39w/sTrXnPCVStNSdvG887vEVGHMJx0WEsXL7vtU
aG5abQ/rPmoYF//SUhAbhYPXXmQhWopGwBobx1cwnnbUEdqEaiuTqGW8eYWiVo3y
ziULbj5H9oH/k9q0SOtGjfrF7nIUVgp48CfRprSFKsCKFYYdZ5Hj58TmuEoGRTiO
4kDCAXCWK3E=
=/Jnb
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list