Gentoo Archives: gentoo-dev

From: Alec Warner <antarus@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFD: EAPI specification in ebuilds
Date: Thu, 08 Mar 2012 04:13:35
In Reply to: [gentoo-dev] RFD: EAPI specification in ebuilds by Ulrich Mueller
On Wed, Mar 7, 2012 at 12:41 PM, Ulrich Mueller <ulm@g.o> 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): > >   EAPI=4 >   EAPI="4" >   EAPI='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=10 and N=30 >  have been suggested). > - The statement must match the following regular expression (extended >  regexp syntax): >  ^[ \t]*EAPI=(['"]?)([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=10, or 2 packages for N=30). > > 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 >    result of the EAPI parsing would be discarded for earlier EAPIs).
I don't like this idea because the sane way should be easy and straightforward. Mixing a constant declaration with bash assignment just confuses users who think the assignment is full bash when in fact it is not. EAPI=$(somefunc) EAPI=${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=$(somefunc) # EAPI=${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 >  the ebuild's header, as follows: > - The first line of the ebuild must contain the word "ebuild", >  followed by whitespace, followed by the EAPI, followed by >  end-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 >    .ebuild -> .eb. > 2b) The usual EAPI assignment statement in the ebuild is still >    required, 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=5 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?


Subject Author
Re: [gentoo-dev] RFD: EAPI specification in ebuilds Ulrich Mueller <ulm@g.o>
Re: [gentoo-dev] RFD: EAPI specification in ebuilds "Michał Górny" <mgorny@g.o>