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 1DjHWy-0006op-OX for garchives@archives.gentoo.org; Fri, 17 Jun 2005 14:09:13 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j5HE7UVY001998; Fri, 17 Jun 2005 14:07:30 GMT Received: from relay4.poste.it (relay4.poste.it [62.241.4.29]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j5HE5Y7n007056 for ; Fri, 17 Jun 2005 14:05:34 GMT Received: from flameeyes.is-a-geek.org (151.44.23.38) by relay4.poste.it (7.2.052.3) (authenticated as emanuela.zanon@poste.it) id 4291DC3F000C39F1 for gentoo-dev@lists.gentoo.org; Fri, 17 Jun 2005 16:05:42 +0200 From: "Diego 'Flameeyes' =?utf-8?q?Petten=C3=B2?=" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Discussion: alternative compatible utilities Date: Fri, 17 Jun 2005 16:05:32 +0200 User-Agent: KMail/1.8.1 References: <200506160757.19214@enterprise.flameeyes.is-a-geek.org> <20050617023226.GA11455@mustard.flatmonk> In-Reply-To: <20050617023226.GA11455@mustard.flatmonk> 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; boundary="nextPart4219568.9ObgeoGfpK"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506171605.39304@enterprise.flameeyes.is-a-geek.org> X-Archives-Salt: 98da2789-45cc-4fab-9cc0-a0313031cf93 X-Archives-Hash: 3888a1f64a473b97bb7b81f13f391179 --nextPart4219568.9ObgeoGfpK Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 differen= t=20 flavours.. so that's why we can use eselect so that it can be adapted "on t= he=20 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= =20 BSD. And actually it has no idea currently about that on G/FBSD or G/OSX.. = we=20 condition this using aliases, but the long-term goal is to avoid this. > So far we've been free to exploit GNU extensions (aka=20 > 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=20 completely but.. .we can ask *explicitely* for GNU tools in those cases=20 (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 ar= e a=20 few ./configure which, knowing they need GNU make, in a system where make i= s=20 BSD and gmake is GNU, launching "make" then exec gmake to do the actual wor= k. > 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 have= n't=20 had too much trouble with that before on G/FBSD, for example the only=20 autotool-created makefile which failed on BSD make was gawk, and that just= =20 because it used $(RM) var directly; most ./configure scripts checks for rm= =20 and creates $(RM) var themselves when make !=3D 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 fo= r=20 example we don't need tar and about find we can use the BSD's one with=20 ebuilds. Anyway, as I already had done, I'm here to fix in case something is using t= he=20 wrong way... after a couple of examples this can be quite simple as for the= =20 old gnu-find dependent ebuilds which are now fixed. =2D-=20 Diego "Flameeyes" Petten=C3=B2 Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) --nextPart4219568.9ObgeoGfpK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBCstize2h1+2mHVWMRAi9ZAKCPs0FaMXmP2YO9bxSXaxn1x7A/JwCglzPJ EqO/nxZBOxhRET5kp/3iocY= =iui1 -----END PGP SIGNATURE----- --nextPart4219568.9ObgeoGfpK-- -- gentoo-dev@gentoo.org mailing list