Gentoo Archives: gentoo-dev

From: Ulrich Mueller <ulm@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: [gentoo-dev] RFD: EAPI specification in ebuilds
Date: Wed, 07 Mar 2012 20:42:13
1 Hi all,
3 The way how we currently specify the EAPI in ebuilds has some
4 problems. For example, there is no sane way to allow usage of features
5 of a new bash version in a new EAPI. So we are currently stuck with
6 bash 3.2. Also changes of global scope behaviour, like addition of new
7 global scope functions (similar to "inherit") are not possible.
9 These flaws are outlined in GLEP 55 [1]:
10 | In order to get the EAPI the package manager needs to source the
11 | ebuild, which itself needs the EAPI in the first place. Otherwise it
12 | imposes a serious limitation, namely every ebuild, using any of the
13 | future EAPIs, will have to be source'able by old package managers
14 | [...]
16 The council has voted down GLEP 55 more than a year ago, but at the
17 same time requested that a solution for the mentioned issues should be
18 found. [2] However, there was no progress since then.
20 The issue arose again in bug 402167 [3] where several solutions have
21 been discussed. Below, I try to summarise the possible options
22 resulting from that discussion.
25 *** Proposal 1: "Parse the EAPI assignment statement" ***
27 This first proposal would require that the syntax of the EAPI
28 assignment statement in ebuilds matches a well defined regular
29 expression. A scan of the Portage tree shows that the statement only
30 occurs in the following variations (using EAPI 4 as example):
32 EAPI=4
33 EAPI="4"
34 EAPI='4'
36 Sometimes this is followed by whitespace or a comment (starting with
37 a # sign). Also, with very few exceptions the EAPI assignment occurs
38 within the first few lines of the ebuild. For the vast majority of
39 ebuilds it is in line 5.
41 Written in a more formal way, appropriate for a specification:
42 - Ebuilds must contain at most one EAPI assignment statement.
43 - It must occur within the first N lines of the ebuild (N=10 and N=30
44 have been suggested).
45 - The statement must match the following regular expression (extended
46 regexp syntax):
47 ^[ \t]*EAPI=(['"]?)([A-Za-z0-9._+-]*)\1[ \t]*(#.*)?$
49 Note: The first and the third point are already fulfilled by all
50 ebuilds in the Portage tree. The second point will require very few
51 ebuilds to be changed (9 packages for N=10, or 2 packages for N=30).
53 The package manager would determine the EAPI by parsing the assignment
54 with above regular expression. A sanity check would be added. Citing
55 Zac Medico in [3]: "The fact that we can compare the probed EAPI to
56 the actual EAPI variable after the ebuild is sourced seems like a
57 perfect sanity check. We could easily detect inconsistencies and flag
58 such ebuilds as invalid, providing a reliable feedback mechanism to
59 ebuild developers."
61 This proposal comes in two variants:
62 1a) The change is applied retroactively for all EAPIs.
63 1b) It is only applied for EAPI 5 and later (which means that the
64 result of the EAPI parsing would be discarded for earlier EAPIs).
67 *** Proposal 2: "EAPI in header comment" ***
69 A different approach would be to specify the EAPI in a specially
70 formatted comment in the ebuild's header. No syntax has been suggested
71 yet, but I believe that the following would work as a specification:
72 - The EAPI must be declared in a special comment in the first line of
73 the ebuild's header, as follows:
74 - The first line of the ebuild must contain the word "ebuild",
75 followed by whitespace, followed by the EAPI, followed by
76 end-of-line or whitespace.
78 Again, the proposal comes in two variants:
79 2a) It is combined with a one time change of the file extension, like
80 .ebuild -> .eb.
81 2b) The usual EAPI assignment statement in the ebuild is still
82 required, at least for a transition period.
84 In the 2a case, the EAPI variable could be made read-only in bash
85 before sourcing the ebuild. In the 2b case, a sanity check similar to
86 the one mentioned above would be added.
89 What do you think?
91 (I really hope for a constructive discussion here. So, if you want
92 to comment that all of the above proposals suck and GLEP 55 is much
93 superior, then please open a new thread for it.)
95 Ulrich
98 [1] <>
99 [2] <>
100 [3] <>


Subject Author
Re: [gentoo-dev] RFD: EAPI specification in ebuilds Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
Re: [gentoo-dev] RFD: EAPI specification in ebuilds Alexis Ballier <aballier@g.o>
Re: [gentoo-dev] RFD: EAPI specification in ebuilds Michael Orlitzky <michael@××××××××.com>
Re: [gentoo-dev] RFD: EAPI specification in ebuilds Alexandre Rostovtsev <tetromino@g.o>
Re: [gentoo-dev] RFD: EAPI specification in ebuilds Alec Warner <antarus@g.o>
Re: [gentoo-dev] RFD: EAPI specification in ebuilds Michael Orlitzky <michael@××××××××.com>
Re: [gentoo-dev] RFD: EAPI specification in ebuilds Mike Gilbert <floppym@g.o>
Re: [gentoo-dev] RFD: EAPI specification in ebuilds "Michał Górny" <mgorny@g.o>
Re: [gentoo-dev] RFD: EAPI specification in ebuilds Walter Dnes <waltdnes@××××××××.org>
Re: [gentoo-dev] RFD: EAPI specification in ebuilds Ralph Sennhauser <sera@g.o>
[gentoo-dev] Re: RFD: EAPI specification in ebuilds Ulrich Mueller <ulm@g.o>