Patrick Lauer wrote:
If I should have forgotten any approach or misrepresented one I'd
appreciate an updated or rephrased section so it can be easily
updated.
This keeps coming up for some reason:
parsers: It enforces some minor limitations, for example EAPI needs to
be unique and cannot be overridden by eclasses.
I agree with this sentence. However, the exact same limitation applies
to GLEP55 and it isn't mentioned there. So, that paragraph should read:
glep55: See GLEP55. To summarize: The eapi is put into the file name so
that the package manager knows the EAPI (and thus how to handle this
file format). While it simplifies the eapi discovery this comes at a
high price as there is no reliable way to find and validate all ebuilds.
It also enforces some minor limitations, for example EAPI needs to be
unique and cannot be overridden by eclasses. Some people also see it as
bad design as it exposes file internals in the filename.
Likwise, the pro/con list for glep55 should include the line:
(+-) enforces some restriction on the possible changes in future EAPIs
In this particular regard the parser and the glep55 approach have the
exact same limitations.
Now, an alternative to glep55 that has two different EAPI-like values
(one for the initial file parsing and one for actually performing the
build) might lose this limitation. However, this is not the case with
glep55 as it is presently stated.
