| 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 |
| 8 |
|
| 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. |
| 11 |
|
| 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> |
| 21 |
|
| 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. |
| 26 |
|
| 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. |
| 34 |
|
| 35 |
-- |
| 36 |
Jim Ramsay |
| 37 |
Gentoo Developer (rox/fluxbox/gkrellm/vim) |
Archives