18.08.2014 16:56, hasufell пишет: > 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. >
As i said early - always override necessary functions if you want non-default behaviour. Proposed solution with variable just add syntax sugar, doing the same thing. As for you as sunrise reviewer. I am member of proxy maintainers, i am also reviewing ebuilds from users. And they usually understands inherit logic very well, even in non-trivial cases. So, your expirience just differs with mine, not more, not less. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Proxy maintainers project lead
signature.asc
Description: OpenPGP digital signature
