| 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 |
> |
| 8 |
|
| 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) |
| 19 |
|
| 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. |
| 27 |
|
| 28 |
Thanks for your real-world examples. |
| 29 |
|
| 30 |
-- |
| 31 |
Rich |
Archives