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