I have no strong opinion about this. > 2) EAPI in file extension > - Allows changing global scope and the internal format of the ebuild > a) .ebuild-<eapi> > - ignored by current Portage
simple, straightforward but ugly > b) .<eapi>.ebuild > - current Portage does not work with this this only has disadvantages in front of a) > c) .<eapi>.<new extension> > - ignored by current Portage same as a) but maybe less ugly > 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 This doesn't need a locked down place, just some strict way of setting it, like at most one EAPI="constant_string_without_space" so that grep & friends can catch it. > - Does not allow changing versioning rules unless version becomes a > normal metadata variable I'm not entirely sure about this and would need some real example/argument in order to be convinced > * Needs more accesses to cache as now you don't have to load older > versions if the latest is not masked true but this "more" would need to be measured and opposed to the number of metadata loads in a dep resolution procedure. > a) <new extension> doesn't have the one year wait drawback and doesn't mess with pm implementation details (eapi) with package names that shall represent upstream ones. > b) new subdirectory like ebuilds/ > - we could drop extension all together so don't have to argue about > it any more > - more directory reads to get the list of ebuilds in a repository I see no advantage there vs 3.a) > c) .ebuild in current directory > - needs one year wait That could have been done one year ago and would be done now; I think it's still fine now because I don't expect major behavior changes in the ebuild format within one year. To summarize, I would retain 3.a as best solution, having the "usable right now" advantage of current glep55 and keeping the ebuild's file names (more or less) consistent with upstream ones. Alexis.
signature.asc
Description: PGP signature
