hasufell: > > Even more interesting... you can work around this by inheriting > base.eclass explicitly before e.g. unpacker.eclass, something like > > inherit base unpacker games > > => unpacker_src_unpack() is carried out by default (and the ebuild > breaks if someone thinks the base.eclass is useless and removes it) > > inherit unpacker games > > => unpacker_src_unpack is not carried out by default although > games.eclass does not directly overwrite it > > If you think any of this is sensible... >
Almost forgot, of course this does not work if you expect unpacker_src_unpacker() to run: inherit unpacker games base as well as inherit unpacker base games however inherit games unpacker base will work. And now... guess why the games herd made it a policy to always inherit games.eclass last. Because of the unpredictability of eclasses and that they may randomly add exported phase functions. It's a bit paranoid, but understandable, since we don't have any real rules here. 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.
