Gentoo Archives: gentoo-dev

From: hasufell <hasufell@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] rfc: calling all eclass phase functions by default
Date: Mon, 18 Aug 2014 13:28:05
Message-Id: 53F1FF47.2080606@gentoo.org
In Reply to: Re: [gentoo-dev] rfc: calling all eclass phase functions by default by Chris Reffett
1 Chris Reffett:
2 > On 8/18/2014 8:56 AM, hasufell wrote:
3 >> hasufell:
4 >>>
5 >>> Even more interesting... you can work around this by inheriting
6 >>> base.eclass explicitly before e.g. unpacker.eclass, something like
7 >>>
8 >>> inherit base unpacker games
9 >>>
10 >>> => unpacker_src_unpack() is carried out by default (and the ebuild
11 >>> breaks if someone thinks the base.eclass is useless and removes it)
12 >>>
13 >>> inherit unpacker games
14 >>>
15 >>> => unpacker_src_unpack is not carried out by default although
16 >>> games.eclass does not directly overwrite it
17 >>>
18 >>> If you think any of this is sensible...
19 >>>
20 >>
21 >> Almost forgot, of course this does not work if you expect
22 >> unpacker_src_unpacker() to run:
23 >> inherit unpacker games base
24 >>
25 >> as well as
26 >> inherit unpacker base games
27 >>
28 >> however
29 >> inherit games unpacker base
30 >>
31 >> will work.
32 >>
33 >> And now... guess why the games herd made it a policy to always inherit
34 >> games.eclass last. Because of the unpredictability of eclasses and that
35 >> they may randomly add exported phase functions. It's a bit paranoid, but
36 >> understandable, since we don't have any real rules here.
37 >>
38 >> So in the end 3 eclasses all tell you "inherit me last! really!". Good
39 >> luck with figuring out how to make a gnome game with python and multilib
40 >> support work together. I can predict the days such a review would take
41 >> in #gentoo-sunrise. Not less than 3.
42 >>
43 > Would it be feasible to add a repoman check for situations like this,
44 > where the behavior of a phase is dependent on inherit order? If so, it
45 > seems reasonable to me to require explicit calls to eclass functions in
46 > these cases to make it clear what's being called when.
47 >
48
49 It would be feasible to turn off this implicit behavior. Adding repoman
50 checks for these kind of things will just yell out the pitfalls instead
51 of actually fixing them. People will still have to read through all the
52 eclasses in order to know what to do. We need something you can rely on.
53 EXPORT_FUNCTIONS line in the ebuild is currently not reliable, because
54 we allow indirect exports.
55
56 So we are back to the last proposal of williamh.