/[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.4 Revision 1.6
1GLEP: 55 1GLEP: 55
2Title: Use EAPI-suffixed ebuilds (.ebuild-EAPI) 2Title: Use EAPI-suffixed ebuilds (.ebuild-EAPI)
3Version: $Revision: 1.4 $ 3Version: $Revision: 1.6 $
4Last-Modified: $Date: 2009/05/17 17:00:30 $ 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
215problems 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
216second 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
217are 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
218given system. 225given system.
219 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
220Summary of ideas 232Summary of ideas
221================ 233================
222 234
223EAPI-suffixed ebuilds (proposed solution) 235EAPI-suffixed ebuilds (proposed solution)
224----------------------------------------- 236-----------------------------------------
256Performance 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
257picture 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
258picking 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
259ebuild) for each available ebuild. 271ebuild) for each available ebuild.
260 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.
261 306
262Easily fetchable EAPI inside the ebuild and one-time extension change 307Easily fetchable EAPI inside the ebuild and one-time extension change
263--------------------------------------------------------------------- 308---------------------------------------------------------------------
264 309
265Properties: 310Properties:

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

  ViewVC Help
Powered by ViewVC 1.1.20