Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Richard Freeman]

Petteri Räty wrote:
> 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

I don't see how this follows.  The PM can compare the mtime on the file 
with the time the cache was updated and refresh if needed.  Or we could 
require users to manually refresh the cache if they modify an ebuild.

>   - Does not allow changing versioning rules unless version becomes a
>     normal metadata variable

I don't see how this follows.  You can put any version in the filename 
that you like just as with the EAPI in the filename approach.  A package 
manager won't process the filename if it doesn't understand the EAPI. 
The order of processing for a package manager would be:
1.  Scan for files named *.ebuild.
2.  Scan the nth line inside to obtain the EAPI.
3.  Take further action in accordance with the EAPI - possibly including 
obtaining the package name/version from the filename, or maybe somewhere 
else entirely.

>     * Needs more accesses to cache as now you don't have to load older
>       versions if the latest is not masked

Why wouldn't you cache every version of a package with its EAPI for 
reference?  I don't follow why this needs more cache hits.  However, 
even if you had to hit the cache more often I don't see why a cache 
lookup would be expensive.  Isn't it stored in a sensible format for 
rapid random access?

My preference is obviously for embedding the EAPI inside the file in 
some manner.  My second preference would be for only changing the file 
extension on rare occasions that are individually approved by the 
Council when things need to change dramatically, as opposed to any time 
the EAPI changes.