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 1Lbg4K-0003wY-DY for garchives@archives.gentoo.org; Mon, 23 Feb 2009 19:02:20 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 75936E04ED; Mon, 23 Feb 2009 19:02:18 +0000 (UTC) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by pigeon.gentoo.org (Postfix) with ESMTP id 47325E04ED for ; Mon, 23 Feb 2009 19:02:18 +0000 (UTC) Received: by wf-out-1314.google.com with SMTP id 29so2327564wff.10 for ; Mon, 23 Feb 2009 11:02:17 -0800 (PST) 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 Sender: antarus@scriptkitty.com Received: by 10.142.223.4 with SMTP id v4mr2116569wfg.11.1235415737796; Mon, 23 Feb 2009 11:02:17 -0800 (PST) In-Reply-To: <20090223155320.4b9f16fd@snowcone> References: <1234257125.18160.2016.camel@localhost> <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> Date: Mon, 23 Feb 2009 11:02:17 -0800 X-Google-Sender-Auth: 27077af9d31d4d3c Message-ID: Subject: Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) From: Alec Warner To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 26e651ee-a38a-4a60-93c9-eb769af4c521 X-Archives-Hash: 3d5722012ff639fb35cd06540c0b8ddb On Mon, Feb 23, 2009 at 7:53 AM, 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? > > Not true. This is entirely legal: > > In pkg-1.ebuild: > > EAPI="${PV}" > printf -v EAPI '%s' 4 > inherit foo > EAPI="2" > > In foo.eclass: > > EAPI="3" This is not legal, the devmanual[1] explicitly states that it is not legal to set EAPI in an eclass. If it was you would have an open and shut case for g55 (since you could set EAPI based on PV in an eclass and then inherit the eapi; requiring a bash parser). But its illegal, which makes your argument harder. A bad argument is EAPI based on some PV logic that you can copy across ebuilds that differ by version; which would fall into 'stupid' in my book. [1] http://devmanual.gentoo.org/ebuild-writing/eapi/index.html > > And in this case, the package manager has to know that EAPI=2, 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="3" > > In global pkg.eclass: > > EAPI="2" Also illegal, but I assume here you intend to change the legality of things in your weird future example. > > 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="2" in the per-pkg eclass and > EAPI="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. > > -- > Ciaran McCreesh >