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: Mon, 18 Aug 2014 14:13:34
In Reply to: Re: [gentoo-dev] rfc: calling all eclass phase functions by default by hasufell
1 On Mon, Aug 18, 2014 at 8:56 AM, hasufell <hasufell@g.o> wrote:
2 >
3 > So in the end 3 eclasses all tell you "inherit me last! really!". Good
4 > luck with figuring out how to make a gnome game with python and multilib
5 > support work together. I can predict the days such a review would take
6 > in #gentoo-sunrise. Not less than 3.
7 >
9 And hence my point about when not to use wraparound eclasses:
10 We get into trouble when we use wraparound eclasses:
11 1. With a broad assortment of ebuilds. (games, check, multilib,
12 check, python, check)
13 2. With many individual ebuild maintainers. (games, check (though
14 we've apparently been trying hard to reduce the number of people
15 willing to deal with them), multilib, check, python, check)
16 3. For things like languages or genres. (games, check, python, check)
17 4. In situations where multiple wraparound eclasses could apply. (the
18 example above - really just the result of #1-3)
20 Really, gnome is the only thing in your list that might justify a
21 wraparound eclass. Even then, I'd use it more for the case of the
22 hundred packages or so that are part of gnome proper, and not every
23 package that somehow integrates with gnome where gnome isn't the
24 upstream. Gnome really should have a utility eclass for broad package
25 support, augmented by a wraparound (that perhaps uses the utility
26 eclass) for the large number of gnome-proper packages.
28 Thanks for your real-world examples.
30 --
31 Rich