On 8/18/2014 8:56 AM, hasufell wrote: > 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. > Would it be feasible to add a repoman check for situations like this, where the behavior of a phase is dependent on inherit order? If so, it seems reasonable to me to require explicit calls to eclass functions in these cases to make it clear what's being called when.
Chris Reffett
