Petteri Räty <betelge...@gentoo.org> wrote: > 2) EAPI in file extension > - Allows changing global scope and the internal format of the ebuild > a) .ebuild-<eapi> > - ignored by current Portage > c) .<eapi>.<new extension> > - ignored by current Portage
Any of the above are fine with me, there is a demonstrated need for this to introduce changes that current portage could not handle. > 3) EAPI in locked down place in the ebuild > - Allows changing global scope > - EAPI can't be changed in an existing ebuild so the PM can trust > the value in the cache > - Does not allow changing versioning rules unless version becomes a > normal metadata variable > * Needs more accesses to cache as now you don't have to load older > versions if the latest is not masked > a) <new extension> 3.a is just like glep-55, except that the filename extension doesn't change all the time. I like that this will have the benefits of glep-55 plus the benefits of making happy the people who don't want the EAPI in the filename or the extension to change very often. This will effectively change a single EAPI number into a major/minor pair. The major part (the extension name) would only ever change when a major feature is introduced that breaks the current portage rules. The internal EAPI, specified however we like in the major format specification, could be in a fixed location or otherwise easily parseable. Then small changes would alter this minor/internal EAPI value. -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim)
