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 1S5UjP-0006TE-7P for garchives@archives.gentoo.org; Thu, 08 Mar 2012 04:13:35 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6EEF1E0686; Thu, 8 Mar 2012 04:13:21 +0000 (UTC) Received: from mail-ww0-f53.google.com (mail-ww0-f53.google.com [74.125.82.53]) by pigeon.gentoo.org (Postfix) with ESMTP id C3913E0667 for ; Thu, 8 Mar 2012 04:12:26 +0000 (UTC) Received: by wgbfm10 with SMTP id fm10so61843wgb.10 for ; Wed, 07 Mar 2012 20:12:26 -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 Received: by 10.180.83.42 with SMTP id n10mr9008080wiy.9.1331179945883; Wed, 07 Mar 2012 20:12:25 -0800 (PST) Sender: antarus@scriptkitty.com Received: by 10.227.5.138 with HTTP; Wed, 7 Mar 2012 20:12:25 -0800 (PST) In-Reply-To: <20311.51166.725757.212932@a1i15.kph.uni-mainz.de> References: <20311.51166.725757.212932@a1i15.kph.uni-mainz.de> Date: Wed, 7 Mar 2012 20:12:25 -0800 X-Google-Sender-Auth: WtDSpRRX1iSAkHeDsooFL21fxFg Message-ID: Subject: Re: [gentoo-dev] RFD: EAPI specification in ebuilds From: Alec Warner To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlf7/xpClkM4YRggitiKhEkKf5ddYV9gNnGChHzJ1w5zzewIbcKQQGkPrf9Q3bMsgSDi2xm X-Archives-Salt: bb987ddd-f00b-4ba8-9bc9-d9e9a765d797 X-Archives-Hash: 06b81e339704b913e721320d6acdc577 On Wed, Mar 7, 2012 at 12:41 PM, Ulrich Mueller wrote: > Hi all, > > The way how we currently specify the EAPI in ebuilds has some > problems. For example, there is no sane way to allow usage of features > of a new bash version in a new EAPI. So we are currently stuck with > bash 3.2. Also changes of global scope behaviour, like addition of new > global scope functions (similar to "inherit") are not possible. > > These flaws are outlined in GLEP 55 [1]: > | In order to get the EAPI the package manager needs to source the > | ebuild, which itself needs the EAPI in the first place. Otherwise it > | imposes a serious limitation, namely every ebuild, using any of the > | future EAPIs, will have to be source'able by old package managers > | [...] > > The council has voted down GLEP 55 more than a year ago, but at the > same time requested that a solution for the mentioned issues should be > found. [2] However, there was no progress since then. > > The issue arose again in bug 402167 [3] where several solutions have > been discussed. Below, I try to summarise the possible options > resulting from that discussion. > > > *** Proposal 1: "Parse the EAPI assignment statement" *** > > This first proposal would require that the syntax of the EAPI > assignment statement in ebuilds matches a well defined regular > expression. A scan of the Portage tree shows that the statement only > occurs in the following variations (using EAPI 4 as example): > > =C2=A0 EAPI=3D4 > =C2=A0 EAPI=3D"4" > =C2=A0 EAPI=3D'4' > > Sometimes this is followed by whitespace or a comment (starting with > a # sign). Also, with very few exceptions the EAPI assignment occurs > within the first few lines of the ebuild. For the vast majority of > ebuilds it is in line 5. > > Written in a more formal way, appropriate for a specification: > - Ebuilds must contain at most one EAPI assignment statement. > - It must occur within the first N lines of the ebuild (N=3D10 and N=3D30 > =C2=A0have been suggested). > - The statement must match the following regular expression (extended > =C2=A0regexp syntax): > =C2=A0^[ \t]*EAPI=3D(['"]?)([A-Za-z0-9._+-]*)\1[ \t]*(#.*)?$ > > Note: The first and the third point are already fulfilled by all > ebuilds in the Portage tree. The second point will require very few > ebuilds to be changed (9 packages for N=3D10, or 2 packages for N=3D30). > > The package manager would determine the EAPI by parsing the assignment > with above regular expression. A sanity check would be added. Citing > Zac Medico in [3]: "The fact that we can compare the probed EAPI to > the actual EAPI variable after the ebuild is sourced seems like a > perfect sanity check. We could easily detect inconsistencies and flag > such ebuilds as invalid, providing a reliable feedback mechanism to > ebuild developers." > > This proposal comes in two variants: > 1a) The change is applied retroactively for all EAPIs. > 1b) It is only applied for EAPI 5 and later (which means that the > =C2=A0 =C2=A0result of the EAPI parsing would be discarded for earlier EA= PIs). I don't like this idea because the sane way should be easy and straightforw= ard. Mixing a constant declaration with bash assignment just confuses users who think the assignment is full bash when in fact it is not. EAPI=3D$(somefunc) EAPI=3D${SOMEVAR%%-*} and so forth all don't meet the regex (and would be flagged invalid.) However a naive author might think they work. I don't think any naive author would think either would work in a comment # EAPI=3D$(somefunc) # EAPI=3D${SOEMVAR%%-*} Bash doesn't parse comments, so confusion is unlikely. > > > *** Proposal 2: "EAPI in header comment" *** > > A different approach would be to specify the EAPI in a specially > formatted comment in the ebuild's header. No syntax has been suggested > yet, but I believe that the following would work as a specification: > - The EAPI must be declared in a special comment in the first line of > =C2=A0the ebuild's header, as follows: > - The first line of the ebuild must contain the word "ebuild", > =C2=A0followed by whitespace, followed by the EAPI, followed by > =C2=A0end-of-line or whitespace. > > Again, the proposal comes in two variants: > 2a) It is combined with a one time change of the file extension, like > =C2=A0 =C2=A0.ebuild -> .eb. > 2b) The usual EAPI assignment statement in the ebuild is still > =C2=A0 =C2=A0required, at least for a transition period. > > In the 2a case, the EAPI variable could be made read-only in bash > before sourcing the ebuild. In the 2b case, a sanity check similar to > the one mentioned above would be added. > > > What do you think? Overloading is bad. There is no real difference between: #!/usr/bin/ebuild --eapi 5 # EAPI=3D5 The problem is that the former is also the way to specify how to execute the ebuild; so unless you plan to make ebuilds executable and having /usr/bin/ebuild provide the ebuild environment, using that syntax is confusing to users. > > (I really hope for a constructive discussion here. So, if you want > to comment that all of the above proposals suck and GLEP 55 is much > superior, then please open a new thread for it.) You don't mention voting on glep 55 again; is there a reason why not? > > Ulrich > > > [1] > [2] > [3] >