From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.105.134.102] (helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1DknkV-0003nn-UN for garchives@archives.gentoo.org; Tue, 21 Jun 2005 18:45:28 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j5LIiQ0o014852; Tue, 21 Jun 2005 18:44:26 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j5LIgk9a007804 for ; Tue, 21 Jun 2005 18:42:46 GMT Received: from agriffis by smtp.gentoo.org with local (Exim 4.43) id 1DkniH-0003zc-IB for gentoo-dev@lists.gentoo.org; Tue, 21 Jun 2005 18:43:09 +0000 Date: Tue, 21 Jun 2005 14:42:55 -0400 X-OfflineIMAP-x251940160-64676f73656e64-494e424f582e4f7574626f78: 1119379390-0413865758009-v4.0.8 From: Aron Griffis To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Discussion: alternative compatible utilities Message-ID: <20050621184255.GJ9452@kaf.zko.hp.com> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <200506160757.19214@enterprise.flameeyes.is-a-geek.org> <20050617023226.GA11455@mustard.flatmonk> <200506171605.39304@enterprise.flameeyes.is-a-geek.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K8nIJk4ghYZn606h" Content-Disposition: inline In-Reply-To: <200506171605.39304@enterprise.flameeyes.is-a-geek.org> User-Agent: Mutt/1.5.8i X-Archives-Salt: 3859bb41-ee87-4a90-a628-218a7bd08c54 X-Archives-Hash: aa7f7a261e5e407add646f833990194d --K8nIJk4ghYZn606h Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Diego 'Flameeyes' Petten=C3=B2 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. >=20 > Well about grep we have no misunderstanding... grep is GNU grep also on t= he=20 > BSD. And actually it has no idea currently about that on G/FBSD or G/OSX.= =2E we=20 > 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... >=20 > 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 --K8nIJk4ghYZn606h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCuF+vJrHF4yAQTrARAprcAJ9V2kABXrUKt2GfiH509G13S0tfsACeKx8B bGi0Fp00c4fWa/8eEl8+fZQ= =Vf1H -----END PGP SIGNATURE----- --K8nIJk4ghYZn606h-- -- gentoo-dev@gentoo.org mailing list