Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>, "Michał Górny" <mgorny@g.o>
Subject: Re: [gentoo-dev] rfc: eclass issues
Date: Sun, 17 Aug 2014 17:29:15
In Reply to: [gentoo-dev] rfc: eclass issues by William Hubbs
1 On Sun, Aug 17, 2014 at 11:38 AM, William Hubbs <williamh@g.o> wrote:
2 >
3 > The other concern he mentioned was indirectly inherited eclasses being
4 > able to override phase functions.
5 >
7 So, while I'm not sure whether getting rid of the ability to inherit
8 phase functions is practical/good/etc, I do think we need to think
9 hard on just what the purpose of an eclass is.
11 This is painting with broad strokes, but I do think there is a case
12 for distinguishing between eclasses used to simplify a large number of
13 closely-related packages (kde/x11/etc), and one used to provide
14 general support to a broad colleciton of packages (python, perl, etc -
15 just about anything named after a language for starters).
17 For the specialized case the inheritance usually isn't a problem,
18 since the packages that inherit it are well-controlled, and while I'm
19 not sure why multiple inheritance is really needed for phase
20 functions, it probably won't be problematic since the use is so well
21 controlled.
23 For eclasses that are broadly used, I think that even inheritance of
24 one layer of phase functions is problematic, let alone multiple ones.
25 What if the same eclass gets pulled in multiple times, etc?
27 Heck, we didn't even want to override things when implementing user
28 patches - we agreed to put it in the default function, and require it
29 to be called when it is overridden, but we didn't aim to automatically
30 call it when it is overriden because of the risk of problems.
32 Why do we need multiple inheritance of phase functions at all? I can
33 see the convenience of allowing one layer, but I think we should
34 consider it a best-practice to avoid it in broadly-used eclasses,
35 unless there is a really good reason not to.
37 Rich