From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LbdRC-0000GJ-08 for garchives@archives.gentoo.org; Mon, 23 Feb 2009 16:13:46 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1BCB1E04EF; Mon, 23 Feb 2009 16:13:28 +0000 (UTC) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by pigeon.gentoo.org (Postfix) with ESMTP id 00A19E04EF for ; Mon, 23 Feb 2009 16:13:26 +0000 (UTC) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id C69B44C816D for ; Mon, 23 Feb 2009 17:13:23 +0100 (CET) Received: from localhost (toz.strangled.net [82.232.126.136]) by smtp4-g21.free.fr (Postfix) with ESMTP id BE0484C807B for ; Mon, 23 Feb 2009 17:13:20 +0100 (CET) Date: Mon, 23 Feb 2009 17:13:16 +0100 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) Message-ID: <20090223171316.5d8f94d0@gentoo.org> In-Reply-To: <20090223155320.4b9f16fd@snowcone> References: <1234257125.18160.2016.camel@localhost> <20090219125124.33eaa66c@snowcone> <1235077892.13198.1923.camel@localhost> <20090222171658.278ae167@halo.dirtyepic.sk.ca> <49A1E1CB.1000806@gentoo.org> <20090222234800.29d64b8d@snowcone> <49A206A7.3050604@gentoo.org> <1235378286.31617.6.camel@neuromancer.neuronics-tp.ch> <49A26B84.7040006@gentoo.org> <1235383347.12908.0.camel@neuromancer.neuronics-tp.ch> <49A2B276.1000109@gentoo.org> <49A2C40D.3060601@gentoo.org> <20090223155320.4b9f16fd@snowcone> Organization: Gentoo X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; x86_64-pc-linux-gnu) 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 Content-Type: multipart/signed; boundary="Sig_/D9LdwNQo7bNzBf67.urQb8T"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 0f4f6628-96a6-4b9f-ac7c-87a3bf44a309 X-Archives-Hash: d567ca6b6ca9ef0f9c2fd1e69e0d1183 --Sig_/D9LdwNQo7bNzBf67.urQb8T Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 23 Feb 2009 15:53:20 +0000 Ciaran McCreesh wrote: > On Mon, 23 Feb 2009 08:43:09 -0700 > Steve Dibb wrote: > > Plus, I don't really grasp the whole "we have to source the whole > > ebuild to know the EAPI version" argument. It's one variable, in > > one line. Can't a simple parser get that and go from there? >=20 > Not true. This is entirely legal: >=20 > In pkg-1.ebuild: >=20 > EAPI=3D"${PV}" > printf -v EAPI '%s' 4 > inherit foo > EAPI=3D"2" Which begs the question: is it really worth allowing it? If we only allow constant assignments (which is an implicit restriction in the file extension version) then this can be parsed easily with grep/tr/awk/etc and can be the magic eapi guessing. Of course the tree has to be checked before implementing this and we'll have to wait a good amount of time before breaking the current eapi bash-parsing but I'm not aware of any eapi proposal that would break the current behavior and would be usable in the main tree within a reasonable amount of time such that we can't ignore backward compatibility. > In foo.eclass: >=20 > EAPI=3D"3" I thought this was prohibited. Alexis. --Sig_/D9LdwNQo7bNzBf67.urQb8T Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmiyxwACgkQvFcC4BYPU0pwfACeISx7aM6kjmQkh7H2fLWA7SsX 0O8An229NWNifJWa0PE4HLkAQWdEzua3 =lLcC -----END PGP SIGNATURE----- --Sig_/D9LdwNQo7bNzBf67.urQb8T--