1 |
For quite some time (over a year, actually) we've been discussing the |
2 |
mysterious and often misunderstood GLEP55. |
3 |
[http://www.gentoo.org/proj/en/glep/glep-0055.html] |
4 |
|
5 |
The proposed solution to a problem that is never refined, in short, is to add |
6 |
the EAPI into the ebuild filename "to make things easier". Which is a rather |
7 |
unsubstantiated idea that doesn't really add up if you look at it ... and it |
8 |
adds some artifacts that we've been laughing about for a decade because |
9 |
microsoft did the exact same thing (binding the executable-ness of a file to |
10 |
the filename). |
11 |
|
12 |
Here's just some of the theories in support of GLEP55 that have been thrown at |
13 |
me, and a few words to show how they are not really issues: |
14 |
|
15 |
"You need to know the EAPI to parse the ebuild to find the EAPI" |
16 |
Obviously that's not true, because somehow we manage at the moment. |
17 |
And if one does a small restriction (which doesn't restrict current behaviour |
18 |
because all in-tree ebuilds currently fit within this limitation) it becomes |
19 |
trivial again: |
20 |
|
21 |
Let EAPI be defined as (the part behind the = of) the first line of the ebuild |
22 |
starting with EAPI= |
23 |
|
24 |
As long as ebuilds remain shell-like this is not much of a restriction, and |
25 |
any format that diverges enough to make this inconvenient shouldn't be called |
26 |
an ebuild anyway. Finding the EAPI is then quite unsurprisingly trivial. |
27 |
|
28 |
"You need to parse the ebuild and its eclasses to find the EAPI!" |
29 |
See above, and eclasses shouldn't change EAPI anyway. It leads to lots of |
30 |
strange effects and is implicitly impossible with GLEP55 anyway, so it might |
31 |
be easier to just declare it invalid. |
32 |
|
33 |
"It's slower!" |
34 |
The theory here being that a stat() is needed if it is encoded in the |
35 |
filename, but a stat() followed by an open() to parse it from the file. |
36 |
Well then, just cache it! You can use the mtime to check the cache validity |
37 |
(which means you do a stat() anyway, so with glep55 caching it is actually |
38 |
slower!), and then you have to parse the ebuild anyway for the other metadata. |
39 |
So the "extra" cost of finding the EAPI is ... what extra cost? |
40 |
The only case when it is actually slower is when there is no cache because |
41 |
then you have to parse the ebuild. But that "degenerate" case will only hit |
42 |
some overlay users and people like developers that can wait .3 seconds longer. |
43 |
And ... uhm ... to extract other metadata like DEPENDS you'll have to parse it |
44 |
anyway. |
45 |
|
46 |
"But we need to be able to change things in the future!" |
47 |
Well then. Once we have identified such an issue we can do the changes. Until |
48 |
then it's not even clear if there are such changes, so why should we break |
49 |
current known and predictable behaviour to satisfy a need we don't even have? |
50 |
Make a structured proposal defining a concrete problem in unambiguous terms, |
51 |
list all the ways to solve this issue, including advantages and disadvantages, |
52 |
and we can get it voted on and ratified within a month. |
53 |
|
54 |
"We want to change the versioning rules!" |
55 |
Why do you want that, and what do we gain from it? |
56 |
|
57 |
"Having GLEP55 allows us to add GLEP54 without issues!" |
58 |
Yeah, uhm, the live-ness of an ebuild is an attribute. How about we add it to |
59 |
metadata, as we should for all metadata? Define a key, I don't know ... LIVE ? |
60 |
LIVE="true". There. No need to fix the filename. And now stop mixing up issues |
61 |
because it is highly confusing! |
62 |
|
63 |
"Obviously you don't understand the issue, because if you did you'd support |
64 |
it!" |
65 |
Uhm, obviously you have no idea what you are saying. But just to play along |
66 |
... if it were that obvious we wouldn't have had to discuss it for so long. |
67 |
Maybe understanding the issue forces one to support the current behaviour! |
68 |
|
69 |
|
70 |
A few words in closing - |
71 |
|
72 |
We can encode all the relevant info in "the first line of the ebuild starting |
73 |
with EAPI=" |
74 |
The overhead of parsing out this value for all ebuilds in the tree has been |
75 |
timed at ~2 CPU-seconds by solar. It's negligible. |
76 |
The changes are none at the moment, all that changes is the specification. And |
77 |
if we ever have the need to change things around we can still look at the |
78 |
expected costs and benefits and decide to implement something almost, but not |
79 |
completely unlike GLEP55. And maybe we can now spend the same amount of |
80 |
council-time (it has been eating time for over a year!) to get important |
81 |
things done ... |
82 |
|
83 |
hth, |
84 |
|
85 |
Patrick the bonsaikitten |
86 |
|
87 |
|
88 |
P.S. http://dev.gentooexperimental.org/~dreeevil/whargarbl.jpg |