Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] rfc: calling all eclass phase functions by default
Date: Sun, 17 Aug 2014 12:24:13
In Reply to: Re: [gentoo-dev] rfc: calling all eclass phase functions by default by Ulrich Mueller
1 On Sun, Aug 17, 2014 at 2:54 AM, Ulrich Mueller <ulm@g.o> wrote:
2 >>>>>> On Sat, 16 Aug 2014, William Hubbs wrote:
3 >
4 >> My counter proposal to this is that we stop calling eclass phase
5 >> functions automatically, and to minimize the amount of boilerplating
6 >> we would have to do, we use a variable, such as ECLASS_PHASES which
7 >> would be defined at the ebuild level and contain a list of the
8 >> eclass phase functions we want to run automatically.
9 >
10 > I'm strongly opposed against this proposal, too. Our current system
11 > essentially works. Also, already now you can suppress automatic
12 > calling of phase functions at the eclass level (by not exporting them)
13 > and at the ebuild level (by defining explicit phase functions).
14 >
16 Honestly, I'm not sure that the status quo a great solution. I think
17 we're much better off if eclasses are designed with the need to call
18 them explicitly kept in mind.
20 Rather than one big phase override that does 5 things, they should
21 have 5 separate calls to do each of those things in turn, and perhaps
22 one convenience function that calls all 5 in sequence.
24 Then if you want to use two eclasses that each expect to do 5 things
25 in the same phase you have a hope of being able to call them in a way
26 that makes sense, and not have things break anytime either of the
27 eclasses change.
29 Sure, you CAN work around many of these issues today, but the current
30 practice encourages eclass developers to build their eclasses with the
31 assumption that they are the only eclass around, and to avoid
32 educating their consumers about the need to call functions, little
33 documentation, etc. The thinking is that there is no need for the foo
34 eclass maintainers to warn developers about the need to trigger their
35 new phase function, because it will happen automatically. The problem
36 is that some percentage of the time, this won't actually happen. It
37 is just infrequent enough that we tolerate it.
39 Thinking about it a bit more, the one case where the status quo might
40 be helpful is for eclasses that aren't general-consumption. For
41 example, there are a million kde packages in the tree, and if it makes
42 sense to have each of those just set a few variables in the package
43 and inherit phase functions from a master kde eclass that makes
44 maintenance far simpler. This tends not to cause problems because all
45 the ebuilds that use the eclass are maintained by the same project and
46 are closely related (and I don't think it is a good idea to use this
47 behavior for a kde eclass that anything that links to libkde is
48 intended to use - just for packages that are part of kde-meta and so
49 on).
51 Unfortunately, with our current design we can't exclude inheritance
52 for some eclasses and not others. Possible options to get around this
53 include having different types of eclasses controlled by some setting
54 in the eclass file, something other than eclasses like meta-ebuilds
55 which can be inherited by other ebuilds perhaps with some kind of
56 namespace isolation (like private classes in most programming
57 languages), and two different inherit statements that behave
58 differently (which is basically the same as two kinds of eclasses, but
59 it gives control to the ebuild maintainers instead of the eclass
60 maintainers so that when things change there is a different kind of
61 pain).
63 Ok, I realize I'm thinking out loud here so I'll just leave it at
64 that. I'm open to arguments - I just don't think the current state is
65 as clean as it could be so we really should consider any reasonable
66 proposals for change.
68 Rich