/[gentoo]/xml/htdocs/proj/en/glep/glep-0055.txt
Gentoo

Diff of /xml/htdocs/proj/en/glep/glep-0055.txt

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

Revision 1.3 Revision 1.6
1GLEP: 55 1GLEP: 55
2Title: Use EAPI-suffixed ebuilds (.ebuild-EAPI) 2Title: Use EAPI-suffixed ebuilds (.ebuild-EAPI)
3Version: $Revision: 1.3 $ 3Version: $Revision: 1.6 $
4Last-Modified: $Date: 2009/05/17 15:50:27 $ 4Last-Modified: $Date: 2012/05/09 19:37:01 $
5Author: Piotr Jaroszyński <peper@gentoo.org> 5Author: Piotr Jaroszyński <peper@gentoo.org>
6Status: Draft 6Status: Rejected
7Type: Standards Track 7Type: Standards Track
8Content-Type: text/x-rst 8Content-Type: text/x-rst
9Created: 17-Dec-2007 9Created: 17-Dec-2007
10Post-History: 17-Dec-2007, 22-Dec-2007, 17-May-2009 10Post-History: 17-Dec-2007, 22-Dec-2007, 17-May-2009
11 11
12 "A little learning is a dangerous thing; drink deep, or taste not the Pierian 12 "A little learning is a dangerous thing; drink deep, or taste not the Pierian
13 spring: there shallow draughts intoxicate the brain, and drinking largely 13 spring: there shallow draughts intoxicate the brain, and drinking largely
14 sobers us again." 14 sobers us again."
15 15
16 -- Alexander Pope, An Essay on Criticism 16 -- Alexander Pope, An Essay on Criticism
17
18Status
19======
20
21This GLEP was voted down by the Council in its meeting on 2010-08-23.
22The Council rejected it again in its meeting on 2012-05-08, in favour
23of parsing the EAPI from the bash assignment statement in ebuilds.
17 24
18Abstract 25Abstract
19======== 26========
20 27
21This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for 28This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for
36 * Add new global scope functions in any sane way. 43 * Add new global scope functions in any sane way.
37 44
38 * Extend versioning rules in an EAPI - for example, addition of the scm 45 * Extend versioning rules in an EAPI - for example, addition of the scm
39 suffix - GLEP54 [#GLEP54]_ or allowing more sensible version formats like 46 suffix - GLEP54 [#GLEP54]_ or allowing more sensible version formats like
40 ``1-rc1``, ``1-alpha`` etc. to match upstream more closely. 47 ``1-rc1``, ``1-alpha`` etc. to match upstream more closely.
48
49 * Use newer bash features.
41 50
42 51
43Current behaviour 52Current behaviour
44================= 53=================
45 54
120 129
121 emerge: there are no ebuilds to satisfy "sys-apps/foo" 130 emerge: there are no ebuilds to satisfy "sys-apps/foo"
122 131
123Not the best error message, especially if there are lots of them. 132Not the best error message, especially if there are lots of them.
124 133
134Use newer bash features
135-----------------------
136
137``|&`` is a new type of redirection added in bash-4. It cannot be used even in
138local scope as bash still parses the whole ebuild.
139
140``sys-apps/foo-1.ebuild``::
141
142 EAPI="5"
143
144 foo() {
145 echo "foo" |& cat
146 }
147
148Result::
149
150 /var/lib/gentoo/repositories/peper/sys-apps/foo/foo-1.ebuild: line 8: syntax error near unexpected token `&'
151 /var/lib/gentoo/repositories/peper/sys-apps/foo/foo-1.ebuild: line 8: ` echo "foo" |& cat'
152 *
153 * ERROR: sys-apps/foo-1 failed.
154 * Call stack:
155 * ebuild.sh, line 1879: Called _source_ebuild
156 * ebuild.sh, line 1818: Called die
157 * The specific snippet of code:
158 * source "${EBUILD}" || die "error sourcing ebuild"
159 * The die message:
160 * error sourcing ebuild
161 *
162 * If you need support, post the topmost build error, and the call stack if relevant.
163 * This ebuild is from an overlay: '/var/lib/gentoo/repositories/peper/'
164 * ... done!
165
166 !!! All ebuilds that could satisfy "sys-apps/foo" have been masked.
167 !!! One of the following masked packages is required to complete your request:
168 - sys-apps/foo-1 (masked by: corruption)
169
170Again, not the best error.
171
125Abstract solution 172Abstract solution
126================= 173=================
127 174
128A solution to this problem has to lift those limitations and the only way to do 175A solution to this problem has to lift those limitations and the only way to do
129it is to make the EAPI of an ebuild available to the package managers in a way 176it is to make the EAPI of an ebuild available to the package managers in a way
175problems too. The first is the requirement to have strict EAPI ordering, the 222problems too. The first is the requirement to have strict EAPI ordering, the
176second is ensuring that all the ebuilds for a single category/package-version 223second is ensuring that all the ebuilds for a single category/package-version
177are equivalent, i.e. installing any of them has exactly the same effect on a 224are equivalent, i.e. installing any of them has exactly the same effect on a
178given system. 225given system.
179 226
227Also note that it is not a new restriction. It is already possible to illegally
228have multiple versions with different EAPIs as e.g. ``1.0 == 1.00 == 1.00-r0``
229and hence you could have ``foo-1.0.ebuild`` with EAPI X and ``foo-1.00.ebuild``
230with EAPI Y.
231
180Summary of ideas 232Summary of ideas
181================ 233================
182 234
183EAPI-suffixed ebuilds (proposed solution) 235EAPI-suffixed ebuilds (proposed solution)
184----------------------------------------- 236-----------------------------------------
216Performance decrease comes from the fact that with version format changes in the 268Performance decrease comes from the fact that with version format changes in the
217picture package managers need EAPI to parse the ebuild's version. That means that merely 269picture package managers need EAPI to parse the ebuild's version. That means that merely
218picking the best version of a package requires loading EAPI (from cache or the 270picking the best version of a package requires loading EAPI (from cache or the
219ebuild) for each available ebuild. 271ebuild) for each available ebuild.
220 272
273Here is more or less how the package manager figures out the best available
274version for a package with N versions available.
275
276 * EAPI in the filename
277
278 * Read the directory containing the package - readdir()
279 * For each ebuild, read its EAPI and using that parse its version - no I/O
280 * Sort the versions - no I/O
281 * Going down from the highest to the lowest version
282
283 * Get the metadata from cache - 2 x stat() + read()
284 * break if the version is visible
285
286 * EAPI in the ebuild
287
288 * Read the directory containing the package - readdir()
289 * For each ebuild load its metadata from cache to get its EAPI - N x (2 x stat() + read())
290 * Sort the versions - no I/O
291 * Going down from the highest to the lowest version
292
293 * (metadata is already loaded) - no I/O
294 * break if the version is visible - no I/O
295
296The difference is in for how many versions the package manager needs to hit
297cache. With EAPI in the ebuild it needs to do that for all versions, with EAPI
298in the filename it depends on versions visibility.
299For example, package foo has versions 1, 2, 3, 4, 5 and 6. 6 is masked, 5 is
300~arch and 1,2,3 and 4 are arch. Say, the user accepts only arch for this
301package. With EAPI in the filename it will read metadata only for versions
3026, 5 and 4. With EAPI in the ebuild it needs to load metadata for all versions.
303
304It's hard to say what's the avarage case, but surely the worst case scenario
305(when only the lowest version is visible) is uncommon.
221 306
222Easily fetchable EAPI inside the ebuild and one-time extension change 307Easily fetchable EAPI inside the ebuild and one-time extension change
223--------------------------------------------------------------------- 308---------------------------------------------------------------------
224 309
225Properties: 310Properties:

Legend:
Removed from v.1.3  
changed lines
  Added in v.1.6

  ViewVC Help
Powered by ViewVC 1.1.20