Gentoo Archives: gentoo-dev

From: Jim Ramsay <lack@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Date: Wed, 25 Feb 2009 11:57:33
In Reply to: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives by "Petteri Räty"
1 Petteri Räty <betelgeuse@g.o> wrote:
2 > 2) EAPI in file extension
3 > - Allows changing global scope and the internal format of the ebuild
4 > a) .ebuild-<eapi>
5 > - ignored by current Portage
6 > c) .<eapi>.<new extension>
7 > - ignored by current Portage
9 Any of the above are fine with me, there is a demonstrated need for
10 this to introduce changes that current portage could not handle.
12 > 3) EAPI in locked down place in the ebuild
13 > - Allows changing global scope
14 > - EAPI can't be changed in an existing ebuild so the PM can trust
15 > the value in the cache
16 > - Does not allow changing versioning rules unless version becomes a
17 > normal metadata variable
18 > * Needs more accesses to cache as now you don't have to load older
19 > versions if the latest is not masked
20 > a) <new extension>
22 3.a is just like glep-55, except that the filename extension doesn't
23 change all the time. I like that this will have the benefits of
24 glep-55 plus the benefits of making happy the people who don't want the
25 EAPI in the filename or the extension to change very often.
27 This will effectively change a single EAPI number into a major/minor
28 pair. The major part (the extension name) would only ever change when
29 a major feature is introduced that breaks the current portage rules.
30 The internal EAPI, specified however we like in the major format
31 specification, could be in a fixed location or otherwise easily
32 parseable. Then small changes would alter this minor/internal EAPI
33 value.
35 --
36 Jim Ramsay
37 Gentoo Developer (rox/fluxbox/gkrellm/vim)