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.
