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
pgpsy8TNSPwjF.pgp
Description: PGP signature
