1 |
Dnia 2014-08-16, o godz. 16:54:28 |
2 |
William Hubbs <williamh@g.o> napisał(a): |
3 |
|
4 |
> The initial proposal is to change this behaviour so that the PMS default |
5 |
> phase functions call all matching phase functions from inherited |
6 |
> eclasses in sequence. |
7 |
> |
8 |
> For example: |
9 |
> |
10 |
> - your ebuild inherits foo and bar and each of them have src_unpack |
11 |
> functions. With this new behaviour, the default src_unpack would run |
12 |
> foo_src_unpack, bar_src_unpack, then perform its own actions. |
13 |
|
14 |
Why doesn't it call default_src_unpack too? |
15 |
|
16 |
> I strongly oppose this change, because I feel it will make our |
17 |
> entire tree very unpredictable at best. I realize this might eliminate |
18 |
> boilerplating from our tree. Weighing that against the possible |
19 |
> ramifications in this big of a change in automagic behaviour, I think |
20 |
> the cost is much higher than the gain. |
21 |
|
22 |
'Unpredictable' is very lightly said. 'Complete mayhem' seems much more |
23 |
appropriate. |
24 |
|
25 |
Right now, finding proper phase functions may be a bit hard due to |
26 |
indirect inherits. Imagine all the fun of debugging phase functions |
27 |
when every single indirect inherits adds to the stack. I don't want |
28 |
even to discuss the issue of ordering them all. |
29 |
|
30 |
For example, a quick grep suggests that 72 eclasses declare |
31 |
src_compile(). Now imagine how many eclasses end up inherited in more |
32 |
complex ebuilds. Of course, the final number would be smaller since |
33 |
many eclasses will simply have to drop phase functions to avoid forcing |
34 |
every single ebuild to redefine phases to avoid colliding behavior. |
35 |
|
36 |
However, I exaggerate a bit here. The issue won't hit too many people |
37 |
because the learning curve would look more like a cliff which you will |
38 |
be climbing up upside down using only your tongue, during a storm. |
39 |
|
40 |
> I am also not very comfortable with our current state, because it has |
41 |
> a lot of uncertainty in terms of how the eclass phase functions are |
42 |
> called. |
43 |
|
44 |
That is not really a problem of PMS behavior but a problem with |
45 |
the eclasses. If eclasses were done at least semi-reasonably, you |
46 |
would be able to easily guess which phase functions are exported by |
47 |
which eclass. |
48 |
|
49 |
> My counter proposal to this is that we stop calling eclass phase |
50 |
> functions automatically, and to minimize the amount of boilerplating |
51 |
> we would have to do, we use a variable, such as ECLASS_PHASES which |
52 |
> would be defined at the ebuild level and contain a list of the eclass |
53 |
> phase functions we want to run automatically. |
54 |
> |
55 |
> Going back to my previous example, say your ebuild does the following: |
56 |
> |
57 |
> -- code begins here -- |
58 |
> |
59 |
> inherit foo bar |
60 |
> |
61 |
> # Foo and bar both have src_unpack and src_install functions. |
62 |
> # we want foo's src_unpack and bar's src_install: |
63 |
> |
64 |
> ECLASS_PHASES="foo_src_unpack |
65 |
> bar_src_install" |
66 |
> |
67 |
> -- code ends here --- |
68 |
|
69 |
And how is this exactly different than: |
70 |
|
71 |
src_unpack() { foo_src_unpack; } |
72 |
src_install() { bar_src_install; } |
73 |
|
74 |
forced by your previous idea? As I see it, it's just a redundant way of |
75 |
doing the same thing. A few bytes shorter maybe, at the cost of having |
76 |
to control and consider another variable. |
77 |
|
78 |
What happens if ebuild specifies both ECLASS_PHASES="foo_src_unpack" |
79 |
and explicit src_unpack()? |
80 |
|
81 |
> If ECLASS_PHASES is undefined, I think the default should be to not run |
82 |
> the eclass phase functions. |
83 |
|
84 |
Do we want to run default EAPI phases? Do we want to have an extra |
85 |
variable to control these? |
86 |
|
87 |
> Yes, this means there is some boilerplating. However, there are some |
88 |
> strong advantages: |
89 |
> |
90 |
> - this is no longer dependent on order of inheritance. |
91 |
> - The ebuild author knows exactly which eclass phase functions will |
92 |
> be run. |
93 |
> |
94 |
> Thoughts? |
95 |
|
96 |
The current behavior compared to the two extremes suggested here sounds |
97 |
like a good compromise. It's not perfect but it works very well for |
98 |
most of the ebuilds, keeping only a few overly verbose and a few |
99 |
unpredictable. |
100 |
|
101 |
The first suggested idea is the kind of extreme trying to solve |
102 |
the overly verbose ebuilds. While it could work in the end, it will |
103 |
certainly make getting all ebuilds and eclasses right a pain. Moreover, |
104 |
it is full of pitfalls and hidden issues. |
105 |
|
106 |
The second idea is the complete opposite extreme. It kills all |
107 |
automation, forcing verbose references in every ebuild. Imagine all |
108 |
those simple Perl modules that have to list all the phase functions... |
109 |
and imagine all the extra pitfalls of missing phase function calls. |
110 |
|
111 |
That said, I suggest you focus your efforts on solving the real issue |
112 |
-- that is, fixing the eclasses -- rather than trying to shoehorn |
113 |
an ugly workaround into PMS. |
114 |
|
115 |
-- |
116 |
Best regards, |
117 |
Michał Górny |