1 |
On Thursday 14 May 2009 19:06:51 Patrick Lauer wrote: |
2 |
> For quite some time (over a year, actually) we've been discussing the |
3 |
> mysterious and often misunderstood GLEP55. |
4 |
> [http://www.gentoo.org/proj/en/glep/glep-0055.html] |
5 |
|
6 |
We agree on the latter adjective, if nothing else. |
7 |
|
8 |
> The proposed solution to a problem that is never refined, in short, is to |
9 |
> add the EAPI into the ebuild filename "to make things easier". Which is a |
10 |
> rather unsubstantiated idea that doesn't really add up if you look at it |
11 |
> ... and it adds some artifacts that we've been laughing about for a decade |
12 |
> because microsoft did the exact same thing (binding the executable-ness of |
13 |
> a file to the filename). |
14 |
|
15 |
I wonder where people get this strange delusion that only Windows uses file |
16 |
extensions for anything? |
17 |
|
18 |
> Here's just some of the theories in support of GLEP55 that have been thrown |
19 |
> at me, and a few words to show how they are not really issues: |
20 |
> |
21 |
> "You need to know the EAPI to parse the ebuild to find the EAPI" |
22 |
> Obviously that's not true, because somehow we manage at the moment. |
23 |
|
24 |
Because we haven't yet introduced any changes that would break it. |
25 |
|
26 |
> And if one does a small restriction (which doesn't restrict current |
27 |
> behaviour because all in-tree ebuilds currently fit within this limitation) |
28 |
> it becomes trivial again: |
29 |
> |
30 |
> Let EAPI be defined as (the part behind the = of) the first line of the |
31 |
> ebuild starting with EAPI= |
32 |
> |
33 |
> As long as ebuilds remain shell-like this is not much of a restriction, |
34 |
|
35 |
It's an arbitrary, magical restriction that doesn't follow from the general |
36 |
rules of the language that ebuilds are written in - you said it |
37 |
yourself, "shell-like". "printf -v EAPI 1" is perfectly valid shell (at |
38 |
least if we decide to allow bash 3.1 features), and has the same effect |
39 |
as "EAPI=1" under the rules of the shell, but it's not compatible with your |
40 |
new rule. |
41 |
|
42 |
> "You need to parse the ebuild and its eclasses to find the EAPI!" |
43 |
> See above, and eclasses shouldn't change EAPI anyway. It leads to lots of |
44 |
> strange effects and is implicitly impossible with GLEP55 anyway, so it |
45 |
> might be easier to just declare it invalid. |
46 |
|
47 |
With GLEP 55 it's naturally invalid, and can't possibly be assumed to be |
48 |
valid. If you keep the assignment-like syntax but disallow it in eclasses, |
49 |
it's an extra weird restriction. |
50 |
|
51 |
> "It's slower!" |
52 |
> The theory here being that a stat() is needed if it is encoded in the |
53 |
> filename, but a stat() followed by an open() to parse it from the file. |
54 |
> Well then, just cache it! You can use the mtime to check the cache validity |
55 |
> (which means you do a stat() anyway, so with glep55 caching it is actually |
56 |
> slower!), and then you have to parse the ebuild anyway for the other |
57 |
> metadata. So the "extra" cost of finding the EAPI is ... what extra cost? |
58 |
> The only case when it is actually slower is when there is no cache because |
59 |
> then you have to parse the ebuild. But that "degenerate" case will only hit |
60 |
> some overlay users and people like developers that can wait .3 seconds |
61 |
> longer. And ... uhm ... to extract other metadata like DEPENDS you'll have |
62 |
> to parse it anyway. |
63 |
|
64 |
And people say Gentoo users are ricers... the whole speed argument is a |
65 |
strawman, relevant only to the extent that we don't want to make things |
66 |
noticeably slower than they are already. You claim that GLEP 55 does that, |
67 |
but this claim seems to be based on the assumption that without it there |
68 |
would be no need to parse the filename in any way, which clearly isn't true. |
69 |
|
70 |
> "But we need to be able to change things in the future!" |
71 |
> Well then. Once we have identified such an issue we can do the changes. |
72 |
> Until then it's not even clear if there are such changes, so why should we |
73 |
> break current known and predictable behaviour to satisfy a need we don't |
74 |
> even have? Make a structured proposal defining a concrete problem in |
75 |
> unambiguous terms, list all the ways to solve this issue, including |
76 |
> advantages and disadvantages, and we can get it voted on and ratified |
77 |
> within a month. |
78 |
|
79 |
The same thing happened when EAPI itself was introduced. EAPI support was |
80 |
committed to Portage in late September 2005, but the first new EAPI in |
81 |
mainstream Gentoo was introduced in early October 2007, just over two years |
82 |
later. That's clearly not an argument for rejecting a compatibility |
83 |
mechanism. |
84 |
|
85 |
It's also not necessary to start putting EAPI in the filename as soon as it's |
86 |
approved. The Council could easily state that "once we need to make a change |
87 |
that requires a stronger mechanism than EAPI is currently, we'll do it like |
88 |
this" - no need to reject it, or keep "maybe"ing it for eternity. |
89 |
|
90 |
Of course, there's at least one GLEP 55-scope change that people want already, |
91 |
to the extent that they're making up hacks to work around the lack of it, |
92 |
namely per-package eclasses. I would hope that everyone agrees that a |
93 |
package manager-supported mechanism would be far preferably (I know that |
94 |
vapier does). |
95 |
|
96 |
> "We want to change the versioning rules!" |
97 |
> Why do you want that, and what do we gain from it? |
98 |
|
99 |
Aside from -scm (below), there are various changes suggested at |
100 |
http://lists.exherbo.org/pipermail/exherbo-dev/2009-February/000400.html that |
101 |
would help match various upstream version formats more closely, and reduce |
102 |
the amount of versionator hacking. Even if you don't like any of those |
103 |
examples, the version format has changed in the past, and it would be quite |
104 |
foolish to design around the assumption that it will never happen again. |
105 |
|
106 |
> "Having GLEP55 allows us to add GLEP54 without issues!" |
107 |
> Yeah, uhm, the live-ness of an ebuild is an attribute. |
108 |
|
109 |
No more so than the "1.2ness". "This ebuild installs the latest sources from |
110 |
the repository" is the same class of information as "this ebuild installs |
111 |
version 1.2", and therefore belongs in the same place. |
112 |
|
113 |
> How about we add it |
114 |
> to metadata, as we should for all metadata? Define a key, I don't know ... |
115 |
> LIVE ? LIVE="true". There. No need to fix the filename. And now stop mixing |
116 |
> up issues because it is highly confusing! |
117 |
|
118 |
That still doesn't solve the version ordering issues, as has already been said |
119 |
countless times. |
120 |
|
121 |
> "Obviously you don't understand the issue, because if you did you'd support |
122 |
> it!" |
123 |
> Uhm, obviously you have no idea what you are saying. But just to play |
124 |
> along ... if it were that obvious we wouldn't have had to discuss it for so |
125 |
> long. |
126 |
|
127 |
You'd think so, but it never seems to work out that way. |
128 |
|
129 |
> Maybe understanding the issue forces one to support the current |
130 |
> behaviour! |
131 |
|
132 |
Unlikely. |