1 |
Alistair Bush wrote: |
2 |
> 4) Parsing the ebuild. But what are we parsing?, lets not limit |
3 |
> ourselves to bash, we might want to change languages completely. If it |
4 |
> is bash, what version, what if EAPI is set multiple times, what if its |
5 |
> set in an eclass. |
6 |
|
7 |
How do you do this if you're getting EAPI from the filename? How do you |
8 |
set it multiple times? How do you set it in an eclass if you're getting |
9 |
it from the filename? |
10 |
|
11 |
It seems like when we're talking about just putting the EAPI in a |
12 |
comment line on line x of the ebuild we're barraged with 47 ways that it |
13 |
will limit us, but when we're talking about EAPI in the filename |
14 |
suddenly we're not concerned with those limitations. If it helps maybe |
15 |
we need to split EAPI into two records - one that deals with how to |
16 |
fundamentally parse the file and find out the EAPI, and the other that |
17 |
implements everything else the EAPI does. |
18 |
|
19 |
I will certainly concede that putting it inside the ebuild potentially |
20 |
breaks compatibility with existing package managers. That is certainly |
21 |
a downside to this approach. However, none of the other objections that |
22 |
have been raised appear to hold water. An EAPI in a filename is a blob |
23 |
of text that needs to be parsed out in one particular way with one set |
24 |
of system calls. An EAPI embedded in the file is a blob of text that |
25 |
needs to be parsed out in one particular way with one set of system calls. |
26 |
|
27 |
And if backwards compatibility were a serious issue you could define a |
28 |
new ".ebuild2" file spec that incorporates the EAPI inside the file and |
29 |
current package managers would ignore it. Then you're not changing the |
30 |
file extension every time a new EAPI comes along, and the need to do so |
31 |
could be handled via future GLEPs. Or we could just delay |
32 |
implementation and clean up existing package managers and tell users to |
33 |
migrate. |