1 |
On Thu, 14 May 2009 20:06:51 +0200 |
2 |
Patrick Lauer <patrick@g.o> wrote: |
3 |
> "You need to know the EAPI to parse the ebuild to find the EAPI" |
4 |
> Obviously that's not true, because somehow we manage at the moment. |
5 |
> And if one does a small restriction (which doesn't restrict current |
6 |
> behaviour because all in-tree ebuilds currently fit within this |
7 |
> limitation) it becomes trivial again: |
8 |
> |
9 |
> Let EAPI be defined as (the part behind the = of) the first line of |
10 |
> the ebuild starting with EAPI= |
11 |
|
12 |
Uh, so horribly utterly and obviously wrong. |
13 |
|
14 |
inherit foo |
15 |
EAPI=4 |
16 |
|
17 |
where foo is both a global and a non-global eclass that sets metadata. |
18 |
|
19 |
If you're looking for a formally correct alternative that works in the |
20 |
way you suggest, I already provided one, and you already read about it |
21 |
-- and it still doesn't solve the problems that 55 does. |
22 |
|
23 |
> "It's slower!" |
24 |
> The theory here being that a stat() is needed if it is encoded in the |
25 |
> filename, but a stat() followed by an open() to parse it from the |
26 |
> file. Well then, just cache it! You can use the mtime to check the |
27 |
> cache validity (which means you do a stat() anyway, so with glep55 |
28 |
> caching it is actually slower!), and then you have to parse the |
29 |
> ebuild anyway for the other metadata. So the "extra" cost of finding |
30 |
> the EAPI is ... what extra cost? The only case when it is actually |
31 |
> slower is when there is no cache because then you have to parse the |
32 |
> ebuild. But that "degenerate" case will only hit some overlay users |
33 |
> and people like developers that can wait .3 seconds longer. And ... |
34 |
> uhm ... to extract other metadata like DEPENDS you'll have to parse |
35 |
> it anyway. |
36 |
|
37 |
Where on earth are you getting the idea that GLEP 55 makes things |
38 |
slower? The only difference to the code with GLEP 55 is in checking |
39 |
file extensions against a slightly larger set of strings, which is |
40 |
nowhere near a measurable increase in anything. You're claiming that |
41 |
checking for a suffix of either ".ebuild-4" or ".ebuild" against a |
42 |
fixed string is in any way relevant, which is obviously trolling. |
43 |
|
44 |
> "Having GLEP55 allows us to add GLEP54 without issues!" |
45 |
> Yeah, uhm, the live-ness of an ebuild is an attribute. How about we |
46 |
> add it to metadata, as we should for all metadata? Define a key, I |
47 |
> don't know ... LIVE ? LIVE="true". There. No need to fix the |
48 |
> filename. And now stop mixing up issues because it is highly |
49 |
> confusing! |
50 |
|
51 |
There is no existing version ordering solution that accurately |
52 |
represents upstream scm branches. |
53 |
|
54 |
> A few words in closing - |
55 |
> |
56 |
> We can encode all the relevant info in "the first line of the ebuild |
57 |
> starting with EAPI=" |
58 |
|
59 |
No we can't. That's *obviously* completely wrong. |
60 |
|
61 |
> The overhead of parsing out this value for all ebuilds in the tree |
62 |
> has been timed at ~2 CPU-seconds by solar. It's negligible. |
63 |
|
64 |
Those of us who have been measuring this have been discarding CPU time |
65 |
entirely, since it's utterly irrelevant. That you bring CPU time into |
66 |
this shows you've been deliberately ignoring everything we've said. |
67 |
|
68 |
We all know you're not stupid enough to believe what you've been |
69 |
posting or ignorant enough to miss the point so badly. So please stop |
70 |
pretending -- this issue would have gone through a long time ago were |
71 |
it not for you and your ilk deliberately pretending to be retarded so |
72 |
you can raise straw man arguments against it rather than addressing the |
73 |
issues at hand. You're doing both yourself and everyone else a huge |
74 |
disfavour by acting dumb and assuming everyone else is going to play |
75 |
along with that. |
76 |
|
77 |
-- |
78 |
Ciaran McCreesh |