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

[hasufell <hasufell@gentoo.org>]

hasufell:
> Sergey Popov:
>> 18.08.2014 16:04, hasufell пишет:
>>>> You have my strong opposition on such change as well. It will turn
>>>> ebuilds into unreadable and undpredictable mess, please do not do that
>>>>
>>>
>>> They are already fairly unreadable and unpredictable.
>>>
>>
>> For you - maybe. But not for me.
>>
>> I am NOT talking about hacks like putting additional *.as files through
>> echo(hello Boost ebuild) or doing something crazy with subshells.
>>
>> But most of the eclass and ebuilds are readable quite simple if you read
>> devmanual, PMS and have a brain.
>>
>> Of course, there are sometimes non-trivial stuff that is hard to read.
>>
>> But majority of ebuilds and eclasses are fine to understand and predict.
>>
>> So, without examples from you, this discussion will lead to nowhere, so,
>> please let's stop it.
>>
> 
> From my time as a sunrise dev I strongly disagree. People have problems
> with understanding the mess, including actual programmers. They have
> enough technical understanding, but not the time or motivation to go
> through all those funny pitfalls which are NOT properly documented in
> devmanual.
> 
> The most popular example is what we are talking about right now:
> indirect inheritance for example via games.eclass which inherits
> base.eclass but does not export src_unpack so stuff like unpacker.eclass
> and git-2.eclass will likely just do nothing if you inherit them before
> games.eclass (which is required by games herd policy)... uhm. I doubt
> you would have guessed this one if you saw the plain ebuild. I know the
> pitfall, so I see it just from looking at the inherit line. But it is
> far from being obvious.
> 

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...