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