1 |
Hi, |
2 |
|
3 |
Here's a patch serie inspired by the recent spidermonkey issue [1]. Long |
4 |
story short, both mozcoreconf-*.eclass and spidermonkey were setting |
5 |
different values of PYTHON_REQ_USE and inherit python-any-r1. Thanks to |
6 |
double include guards, the dependencies were set using the first value |
7 |
on the first iteration. However, python_setup() used the final value, |
8 |
being more strict as a result. |
9 |
|
10 |
This patch series aims to reduce the likeliness of such mistakes, |
11 |
by comparing the values of output variables between successive eclass |
12 |
inherits. This both catches some mistakes of overwriting the value, |
13 |
and any potential integrity issues in eclass itself. |
14 |
|
15 |
The remaining commits are purely cleanup/refactor. |
16 |
|
17 |
However, the following technical limitations need to be noted: |
18 |
|
19 |
1. We can only detect changes of control variables between successive |
20 |
inherits of eclass, which makes every solution highly dependent |
21 |
on the inherit order. If you 'inherit mozcoreconf-v4 python-any-r1', |
22 |
the control variables are overwritten before python-any-r1 can see them. |
23 |
|
24 |
2. There was a suggestion to make the eclass output variables updated |
25 |
for the last values of control. However, the output variables are |
26 |
currently marked readonly, to avoid accidental rewrites. If we were |
27 |
to update them, we would have to disable that. |
28 |
|
29 |
3. The same bugs (and also the case of defining after inherit) could |
30 |
be caught if control variables were made readonly after setting globals. |
31 |
However, this would cause spurious errors if the ebuild was sourced |
32 |
more than once by the PM. |
33 |
|
34 |
Please review. |
35 |
|
36 |
[1]:https://bugs.gentoo.org/611176 |
37 |
|
38 |
-- |
39 |
Best regards, |
40 |
Michał Górny |