1 |
All, |
2 |
|
3 |
there is an ongoing discussion about how we handle eclass phase |
4 |
functions by default [1]. |
5 |
|
6 |
Currently, EXPORT_FUNCTIONS is called in eclasses, and because of the |
7 |
way this works, the phase function that is exported last in the chain of |
8 |
inherited eclasses is the one that is called for a given phase, |
9 |
overriding the PMS default phase function. |
10 |
|
11 |
The initial proposal is to change this behaviour so that the PMS default |
12 |
phase functions call all matching phase functions from inherited |
13 |
eclasses in sequence. |
14 |
|
15 |
For example: |
16 |
|
17 |
- your ebuild inherits foo and bar and each of them have src_unpack |
18 |
functions. With this new behaviour, the default src_unpack would run |
19 |
foo_src_unpack, bar_src_unpack, then perform its own actions. |
20 |
|
21 |
I strongly oppose this change, because I feel it will make our |
22 |
entire tree very unpredictable at best. I realize this might eliminate |
23 |
boilerplating from our tree. Weighing that against the possible |
24 |
ramifications in this big of a change in automagic behaviour, I think |
25 |
the cost is much higher than the gain. |
26 |
|
27 |
I am also not very comfortable with our current state, because it has |
28 |
a lot of uncertainty in terms of how the eclass phase functions are |
29 |
called. |
30 |
|
31 |
My counter proposal to this is that we stop calling eclass phase |
32 |
functions automatically, and to minimize the amount of boilerplating |
33 |
we would have to do, we use a variable, such as ECLASS_PHASES which |
34 |
would be defined at the ebuild level and contain a list of the eclass |
35 |
phase functions we want to run automatically. |
36 |
|
37 |
Going back to my previous example, say your ebuild does the following: |
38 |
|
39 |
-- code begins here -- |
40 |
|
41 |
inherit foo bar |
42 |
|
43 |
# Foo and bar both have src_unpack and src_install functions. |
44 |
# we want foo's src_unpack and bar's src_install: |
45 |
|
46 |
ECLASS_PHASES="foo_src_unpack |
47 |
bar_src_install" |
48 |
|
49 |
-- code ends here --- |
50 |
|
51 |
If ECLASS_PHASES is undefined, I think the default should be to not run |
52 |
the eclass phase functions. |
53 |
|
54 |
Yes, this means there is some boilerplating. However, there are some |
55 |
strong advantages: |
56 |
|
57 |
- this is no longer dependent on order of inheritance. |
58 |
- The ebuild author knows exactly which eclass phase functions will |
59 |
be run. |
60 |
|
61 |
Thoughts? |
62 |
|
63 |
William |
64 |
|
65 |
[1] https://bugs.gentoo.org/show_bugs.cgi?id=516014 |