From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1M52cK-0000g9-4F for garchives@archives.gentoo.org; Fri, 15 May 2009 18:58:48 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1DEC6E0464; Fri, 15 May 2009 18:58:47 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id EB251E0464 for ; Fri, 15 May 2009 18:58:46 +0000 (UTC) Received: from [192.168.1.110] (unknown [117.192.134.38]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id AEAE666313 for ; Fri, 15 May 2009 18:58:45 +0000 (UTC) Subject: Re: [gentoo-dev] The fallacies of GLEP55 From: Arun Raghavan To: gentoo-dev@lists.gentoo.org In-Reply-To: <200905150044.20920.patrick@gentoo.org> References: <200905142006.51998.patrick@gentoo.org> <20090514214909.GA23080@linux1> <20090514225337.34df7dac@snowcone> <200905150044.20920.patrick@gentoo.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-GPi7y9wolcNLo/s99UKM" Date: Sat, 16 May 2009 00:28:36 +0530 Message-Id: <1242413916.22752.13.camel@peripatetic.hades> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 X-Archives-Salt: d5eee2b5-6751-4fb9-8e16-d142b686a09b X-Archives-Hash: f71b7a97182fff982e8674a34a0bf3cf --=-GPi7y9wolcNLo/s99UKM Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2009-05-15 at 00:44 +0200, Patrick Lauer wrote: [...] > So if you were a lazy Unix coder you'd just restrict the current rules a = bit=20 > so that there's only one line starting with EAPI=3D allowed (or maybe you= just=20 > take the first or last one, but that's annoying) and if no such line matc= hes=20 > you can safely assume EAPI0 >=20 > Maybe you're very lazy, so you explicitly forbid eclasses from setting or= =20 > changing EAPI. That also avoids weird effects that make you lose lots of = time=20 > for debugging because you didn't think about what would happen if foo.ecl= ass=20 > set EAPI=3D"3.14" and bar.eclass inherited later set EAPI=3D"1" ... >=20 > And magically you haven't really changed current behaviour, can get the E= API=20 > without sourcing it and you can be lazy once more. Isn't it great? As I've stated a long time ago, I'm for this solution. My understanding is that there are 2 objections to this: 1) We can't change the ebuild format to XML or what have you. I think this is a problem to deal with *if it ever happens*. I am completely against trying to solve a problem that will not exist in the foreseeable future. 2) There might be a performance impact for cases where the metadata is uncached - I think the impact is acceptable in the face of the fugliness added by putting the EAPI in the ebuild's name (Joe Peterson summarise this quite well earlier [1]). Really, the key issue seems to be (1), because there's no other good reason to be trying to adopt this GLEP. -- Arun [1] http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg29311.html --=-GPi7y9wolcNLo/s99UKM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkoNu1wACgkQ+Vqt1inD4uyXaACfULrQY/7WsgyB9MP0QeJysa8/ dNYAnjRTpL3xnj9FCmHezZ4nBVUTellp =PPo9 -----END PGP SIGNATURE----- --=-GPi7y9wolcNLo/s99UKM--