1 |
On 8/17/14, 12:32 AM, Kent Fredric wrote: |
2 |
> Collison systems I've seen usually do one of two things: |
3 |
> |
4 |
> - In the event of a collision, demand the consumer resolve the problem by |
5 |
> redefining the function the collision occurs on in terms of its composite |
6 |
> parts. ( which is basically what we already do ) |
7 |
> - Declare syntax to "exclude" a potential collision from either composite |
8 |
> part. |
9 |
> |
10 |
> Our only real difference at present is unlike these systems, we assume we |
11 |
> can simply guess which one wins and just choose it automatically, where |
12 |
> collision systems tend to force you to deal with the situation if any |
13 |
> collision occurs. |
14 |
|
15 |
This makes sense to me. Can we consider starting with just a repoman |
16 |
warning for the collision cases? |
17 |
|
18 |
The warning would make the problem more visible to ebuild writers. Then |
19 |
we already have a solution that works, i.e. explicitly defining the |
20 |
phase function in the ebuild, possibly calling the eclass functions. |
21 |
|
22 |
My understanding is people not being aware of the problem is the main |
23 |
issue here, not the ability to address it. |
24 |
|
25 |
Paweł |
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 |
>> |
62 |
> This proposal, seems reasonable, given my comments. I anticipate however |
63 |
> its biggest downside would be |
64 |
> the requirement to state *all* the functions you want, which would lead to |
65 |
> maintenance headaches |
66 |
> due to people forgetting to declare they wanted some function or other. |
67 |
> |
68 |
> So if you could sculpt it to be broader by default and have less scope for |
69 |
> developer error, that'd be an improvement. |
70 |
> |
71 |
> --- code start -- |
72 |
> ECLASS_EXCLUDE="foo_src_unpack bar_src_unpack" |
73 |
> inherit foo bar baz |
74 |
> |
75 |
> |
76 |
> --- code end --- |
77 |
> |
78 |
> here, src_unpack would be baz_src_unpack *regardless* of composition order |
79 |
> because "foo" and "bar" were barred from being used, and baz took |
80 |
> precedence as a result. |
81 |
> |
82 |
> If baz provides no src_unpack, then the ebuild in question is simply left |
83 |
> without one. |
84 |
> |
85 |
> You'll still need to declare src_unpack explicitly if you need use |
86 |
> conditional behaviour, however. |
87 |
> |