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 1Lbd7a-0006fM-Sb for garchives@archives.gentoo.org; Mon, 23 Feb 2009 15:53:31 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8E50EE045F; Mon, 23 Feb 2009 15:53:29 +0000 (UTC) Received: from mail-fx0-f161.google.com (mail-fx0-f161.google.com [209.85.220.161]) by pigeon.gentoo.org (Postfix) with ESMTP id 2C315E045F for ; Mon, 23 Feb 2009 15:53:29 +0000 (UTC) Received: by fxm5 with SMTP id 5so1854897fxm.10 for ; Mon, 23 Feb 2009 07:53:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=YbE6ZmGwfAj35Qp23KTFWcG/npGmvPEWqDFQ/mSvZ3c=; b=KoKd62iQQ/2DU69SMZHJ9wRR9FRemSWNPNXppa0wyNO9Sj5W5lVWxElkqwKPXtYIyl Lr1vEFyNBhdAQZmZG7UfswgWnQair/SreCMItJmUB7NI27PWpjF3jPQ7f/1UIVHzVbWi Cx2CAJOsWzhEHxGwFlWB2JRU/bUThrWE5QIv0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=rG2xalvyyb4RGcvxA6UCuBbHk85siIAr/oGfZZe5hEDwzsTEO0UizkKrh7G6xMQKYM qdckkoQNUzJshHXMyY+p/tlol454cR9Zzz62tKtiB3RnJWU5NfQ2nFotgYAsf+I9O/kW 2eHa8kAariWBvbVVb7Td9cDVDYwhlHkDCovwg= Received: by 10.103.12.8 with SMTP id p8mr3412105mui.44.1235404408000; Mon, 23 Feb 2009 07:53:28 -0800 (PST) Received: from snowcone (92-235-187-79.cable.ubr18.sgyl.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id k2sm7958848ugf.37.2009.02.23.07.53.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 07:53:27 -0800 (PST) Date: Mon, 23 Feb 2009 15:53:20 +0000 From: Ciaran McCreesh 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: <20090223155320.4b9f16fd@snowcone> In-Reply-To: <49A2C40D.3060601@gentoo.org> 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> 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_/zmvFCcZAOl_dk2CH5vS_PWZ"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 3b8f25e8-08a8-4f61-9555-f80944afad33 X-Archives-Hash: faecbcfd1d7a9c5a60271b52472c6ecc --Sig_/zmvFCcZAOl_dk2CH5vS_PWZ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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? Not true. This is entirely legal: In pkg-1.ebuild: EAPI=3D"${PV}" printf -v EAPI '%s' 4 inherit foo EAPI=3D"2" In foo.eclass: EAPI=3D"3" And in this case, the package manager has to know that EAPI=3D2, and it has to use EAPI 2's behaviour for performing the inherit. In fact, it gets worse if you consider that future EAPIs will probably allow per-package eclasses. So you could end up with this crazy situation: In pkg-1.ebuild: require pkg In cat/pkg/pkg.eclass: EAPI=3D"3" In global pkg.eclass: EAPI=3D"2" So here you can't even use a faked pre-source EAPI. If you assume EAPI 0 beforehand, the global pkg.eclass will be used, so EAPI will end up as 2. But if you assume EAPI 3 beforehand, the per-pkg eclass will be used, so the EAPI will end up as 3. It gets even crazier if you put EAPI=3D"2" in the per-pkg eclass and EAPI=3D"3" in the global one instead... And whilst this is clearly a deliberate example of how to create craziness, the only difference between this and the real world is that the craziness is obvious here. The current rules really are this complicated, and we can't retroactively fix them. --=20 Ciaran McCreesh --Sig_/zmvFCcZAOl_dk2CH5vS_PWZ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmixnIACgkQ96zL6DUtXhFXSgCfVouv8sID1odA02Hj1QNRlEc9 vx0AoMjitzruZokpKPOMZP1Ng8Gq2KaX =VKCA -----END PGP SIGNATURE----- --Sig_/zmvFCcZAOl_dk2CH5vS_PWZ--