Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: William Hubbs <williamh@g.o>
Cc: gentoo development <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] rfc: calling all eclass phase functions by default
Date: Sat, 16 Aug 2014 22:53:43
Message-Id: 20140817005417.5106da3c@pomiot.lan
In Reply to: [gentoo-dev] rfc: calling all eclass phase functions by default by William Hubbs
1 Dnia 2014-08-16, o godz. 16:54:28
2 William Hubbs <williamh@g.o> napisał(a):
4 > The initial proposal is to change this behaviour so that the PMS default
5 > phase functions call all matching phase functions from inherited
6 > eclasses in sequence.
7 >
8 > For example:
9 >
10 > - your ebuild inherits foo and bar and each of them have src_unpack
11 > functions. With this new behaviour, the default src_unpack would run
12 > foo_src_unpack, bar_src_unpack, then perform its own actions.
14 Why doesn't it call default_src_unpack too?
16 > I strongly oppose this change, because I feel it will make our
17 > entire tree very unpredictable at best. I realize this might eliminate
18 > boilerplating from our tree. Weighing that against the possible
19 > ramifications in this big of a change in automagic behaviour, I think
20 > the cost is much higher than the gain.
22 'Unpredictable' is very lightly said. 'Complete mayhem' seems much more
23 appropriate.
25 Right now, finding proper phase functions may be a bit hard due to
26 indirect inherits. Imagine all the fun of debugging phase functions
27 when every single indirect inherits adds to the stack. I don't want
28 even to discuss the issue of ordering them all.
30 For example, a quick grep suggests that 72 eclasses declare
31 src_compile(). Now imagine how many eclasses end up inherited in more
32 complex ebuilds. Of course, the final number would be smaller since
33 many eclasses will simply have to drop phase functions to avoid forcing
34 every single ebuild to redefine phases to avoid colliding behavior.
36 However, I exaggerate a bit here. The issue won't hit too many people
37 because the learning curve would look more like a cliff which you will
38 be climbing up upside down using only your tongue, during a storm.
40 > I am also not very comfortable with our current state, because it has
41 > a lot of uncertainty in terms of how the eclass phase functions are
42 > called.
44 That is not really a problem of PMS behavior but a problem with
45 the eclasses. If eclasses were done at least semi-reasonably, you
46 would be able to easily guess which phase functions are exported by
47 which eclass.
49 > My counter proposal to this is that we stop calling eclass phase
50 > functions automatically, and to minimize the amount of boilerplating
51 > we would have to do, we use a variable, such as ECLASS_PHASES which
52 > would be defined at the ebuild level and contain a list of the eclass
53 > phase functions we want to run automatically.
54 >
55 > Going back to my previous example, say your ebuild does the following:
56 >
57 > -- code begins here --
58 >
59 > inherit foo bar
60 >
61 > # Foo and bar both have src_unpack and src_install functions.
62 > # we want foo's src_unpack and bar's src_install:
63 >
64 > ECLASS_PHASES="foo_src_unpack
65 > bar_src_install"
66 >
67 > -- code ends here ---
69 And how is this exactly different than:
71 src_unpack() { foo_src_unpack; }
72 src_install() { bar_src_install; }
74 forced by your previous idea? As I see it, it's just a redundant way of
75 doing the same thing. A few bytes shorter maybe, at the cost of having
76 to control and consider another variable.
78 What happens if ebuild specifies both ECLASS_PHASES="foo_src_unpack"
79 and explicit src_unpack()?
81 > If ECLASS_PHASES is undefined, I think the default should be to not run
82 > the eclass phase functions.
84 Do we want to run default EAPI phases? Do we want to have an extra
85 variable to control these?
87 > Yes, this means there is some boilerplating. However, there are some
88 > strong advantages:
89 >
90 > - this is no longer dependent on order of inheritance.
91 > - The ebuild author knows exactly which eclass phase functions will
92 > be run.
93 >
94 > Thoughts?
96 The current behavior compared to the two extremes suggested here sounds
97 like a good compromise. It's not perfect but it works very well for
98 most of the ebuilds, keeping only a few overly verbose and a few
99 unpredictable.
101 The first suggested idea is the kind of extreme trying to solve
102 the overly verbose ebuilds. While it could work in the end, it will
103 certainly make getting all ebuilds and eclasses right a pain. Moreover,
104 it is full of pitfalls and hidden issues.
106 The second idea is the complete opposite extreme. It kills all
107 automation, forcing verbose references in every ebuild. Imagine all
108 those simple Perl modules that have to list all the phase functions...
109 and imagine all the extra pitfalls of missing phase function calls.
111 That said, I suggest you focus your efforts on solving the real issue
112 -- that is, fixing the eclasses -- rather than trying to shoehorn
113 an ugly workaround into PMS.
115 --
116 Best regards,
117 Michał Górny


File name MIME type
signature.asc application/pgp-signature


Subject Author
Re: [gentoo-dev] rfc: calling all eclass phase functions by default William Hubbs <williamh@g.o>