1 |
On 11/06/2014 02:16 PM, Jeroen Roovers wrote: |
2 |
> On Thu, 06 Nov 2014 13:42:43 -0800 |
3 |
> Zac Medico <zmedico@g.o> wrote: |
4 |
> |
5 |
>> On 11/06/2014 01:32 PM, Jeroen Roovers wrote: |
6 |
>>> I'm not aware of any current definition of order in eclass |
7 |
>>> inheritance. |
8 |
>> |
9 |
>> Maybe PMS doesn't say anything about the order (yet). However, I'm |
10 |
>> fairly sure that all package managers process eclasses in the same |
11 |
>> order that they are passed as arguments to inherit. Otherwise, |
12 |
>> eclasses would not be able to properly override functions defined by |
13 |
>> eclasses earlier in the inherit chain. |
14 |
> |
15 |
> If the order is important, then the ebuild should call each phase or |
16 |
> utility function explicitly. Expecting the order of inheritance to |
17 |
> convey the same thing instead of making explicit calls might work from |
18 |
> the package manager's perspective, but the ebuild writer is lost in the |
19 |
> woods. With that in mind we might argue that a change in the order of |
20 |
> inheritance should never cause a different outcome. |
21 |
> |
22 |
>> In the context of future.eclass, eutils and multilib could simply |
23 |
>> check if the relevant functions were defined earlier, and die in that |
24 |
>> case. |
25 |
> |
26 |
> Would the bash internal `readonly -f' work for that? |
27 |
|
28 |
Maybe, but the error message would be cryptic. I was thinking something |
29 |
like this: |
30 |
|
31 |
declare -F get_libdir >/dev/null && \ |
32 |
die "multilib.eclass must be inherited before future.eclass" |
33 |
|
34 |
>>> We sure have issues with inheriting eclasses in a different order |
35 |
>>> giving different results now. Is this something that's in the works |
36 |
>>> for a future EAPI, then? |
37 |
>> |
38 |
>> No, but as said, I'm fairly sure that all package managers process |
39 |
>> eclasses in the same order that they are passed as arguments to |
40 |
>> inherit. |
41 |
> |
42 |
> Well, that's convenient but you should probably not start relying on |
43 |
> it now. |
44 |
|
45 |
I think it would be a fine assumption, and Ciaran has noted that PMS |
46 |
already specifies that inherit parameters are considered in order. |
47 |
|
48 |
> In that case we might want to discuss inheriting in |
49 |
> alphabetical order and numbering the eclasses cleverly, too. Or rename |
50 |
> this one to zfuture.eclass. |
51 |
|
52 |
I understand your intentions, but I don't think that's the right |
53 |
solution. I agree with Ciaran's assertion that "it would be much easier |
54 |
if people just stopped writing "clever" eclasses and didn't mix utility |
55 |
functions and phase functions within a single eclass". |
56 |
-- |
57 |
Thanks, |
58 |
Zac |