Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Cc: antarus@g.o
Subject: Re: [gentoo-dev] RFD: EAPI specification in ebuilds
Date: Thu, 08 Mar 2012 12:04:58
Message-Id: 20120308130620.75b45696@pomiocik.lan
In Reply to: Re: [gentoo-dev] RFD: EAPI specification in ebuilds by Alec Warner
1 On Wed, 7 Mar 2012 20:12:25 -0800
2 Alec Warner <antarus@g.o> wrote:
3
4 > On Wed, Mar 7, 2012 at 12:41 PM, Ulrich Mueller <ulm@g.o>
5 > wrote:
6 > > Hi all,
7 > >
8 > > The way how we currently specify the EAPI in ebuilds has some
9 > > problems. For example, there is no sane way to allow usage of
10 > > features of a new bash version in a new EAPI. So we are currently
11 > > stuck with bash 3.2. Also changes of global scope behaviour, like
12 > > addition of new global scope functions (similar to "inherit") are
13 > > not possible.
14 > >
15 > > These flaws are outlined in GLEP 55 [1]:
16 > > | In order to get the EAPI the package manager needs to source the
17 > > | ebuild, which itself needs the EAPI in the first place. Otherwise
18 > > it | imposes a serious limitation, namely every ebuild, using any
19 > > of the | future EAPIs, will have to be source'able by old package
20 > > managers | [...]
21 > >
22 > > The council has voted down GLEP 55 more than a year ago, but at the
23 > > same time requested that a solution for the mentioned issues should
24 > > be found. [2] However, there was no progress since then.
25 > >
26 > > The issue arose again in bug 402167 [3] where several solutions have
27 > > been discussed. Below, I try to summarise the possible options
28 > > resulting from that discussion.
29 > >
30 > >
31 > > *** Proposal 1: "Parse the EAPI assignment statement" ***
32 > >
33 > > This first proposal would require that the syntax of the EAPI
34 > > assignment statement in ebuilds matches a well defined regular
35 > > expression. A scan of the Portage tree shows that the statement only
36 > > occurs in the following variations (using EAPI 4 as example):
37 > >
38 > >   EAPI=4
39 > >   EAPI="4"
40 > >   EAPI='4'
41 > >
42 > > Sometimes this is followed by whitespace or a comment (starting with
43 > > a # sign). Also, with very few exceptions the EAPI assignment occurs
44 > > within the first few lines of the ebuild. For the vast majority of
45 > > ebuilds it is in line 5.
46 > >
47 > > Written in a more formal way, appropriate for a specification:
48 > > - Ebuilds must contain at most one EAPI assignment statement.
49 > > - It must occur within the first N lines of the ebuild (N=10 and
50 > > N=30 have been suggested).
51 > > - The statement must match the following regular expression
52 > > (extended regexp syntax):
53 > >  ^[ \t]*EAPI=(['"]?)([A-Za-z0-9._+-]*)\1[ \t]*(#.*)?$
54 > >
55 > > Note: The first and the third point are already fulfilled by all
56 > > ebuilds in the Portage tree. The second point will require very few
57 > > ebuilds to be changed (9 packages for N=10, or 2 packages for N=30).
58 > >
59 > > The package manager would determine the EAPI by parsing the
60 > > assignment with above regular expression. A sanity check would be
61 > > added. Citing Zac Medico in [3]: "The fact that we can compare the
62 > > probed EAPI to the actual EAPI variable after the ebuild is sourced
63 > > seems like a perfect sanity check. We could easily detect
64 > > inconsistencies and flag such ebuilds as invalid, providing a
65 > > reliable feedback mechanism to ebuild developers."
66 > >
67 > > This proposal comes in two variants:
68 > > 1a) The change is applied retroactively for all EAPIs.
69 > > 1b) It is only applied for EAPI 5 and later (which means that the
70 > >    result of the EAPI parsing would be discarded for earlier EAPIs).
71 >
72 > I don't like this idea because the sane way should be easy and
73 > straightforward. Mixing a constant declaration with bash assignment
74 > just confuses users who think the assignment is full bash when in
75 > fact it is not.
76 >
77 > EAPI=$(somefunc)
78 > EAPI=${SOMEVAR%%-*}
79 > and so forth all don't meet the regex (and would be flagged invalid.)
80 > However a naive author might think they work.
81
82 And they all should be invalid due to our policies. The most important
83 ebuild variables like EAPI should be readable on sight, without having
84 to lookup random variables, functions etc.
85
86 --
87 Best regards,
88 Michał Górny

Attachments

File name MIME type
signature.asc application/pgp-signature