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

[Aron Griffis]

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