Re: [gentoo-dev] rfc: calling all eclass phase functions by default

[Chris Reffett <creffett@gentoo.org>]

On August 18, 2014 11:11:56 AM EDT, "Michał Górny" <mgorny@gentoo.org> wrote:
>Dnia 2014-08-18, o godz. 09:22:46
>Chris Reffett <creffett@gentoo.org> napisał(a):
>
>> On 8/18/2014 8:56 AM, hasufell wrote:
>> > 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.
>
>Right now, we have no kind of repoman for eclasses. If you have time to
>work on such a thing, please do. Otherwise, all we can do is put more
>checks in ebuilds but that triggers the warning for the wrong people...

I was thinking more ebuild-side. Example: my ebuild inherits both cmake-utils and games eclasses, and I don't explicitly define src_compile, repoman full could pop up a warning like "src_compile is ambiguous between cmake-utils_src_compile and games_src_compile, please explicitly define this phase and call the appropriate eclass function." I imagine that this would pop up a lot of warnings, but I feel like it would improve readability and make it explicit what should be going on where. I concede that it could make a lot more boilerplate code in ebuilds, so that's a potential issue, mostly just throwing out an idea here.

Chris Reffett