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

[Rich Freeman]

On Mon, Aug 18, 2014 at 8:21 AM, Sergey Popov <pinkbyte@g.o> wrote:
> 18.08.2014 14:44, Rich Freeman пишет:
>> On Mon, Aug 18, 2014 at 4:54 AM, Sergey Popov <pinkbyte@g.o> wrote:
>>> 17.08.2014 01:54, William Hubbs пишет:
>>>>
>>>> # Foo and bar both have src_unpack and src_install functions.
>>>> # we want foo's src_unpack and bar's src_install:
>>>>
>>>> ECLASS_PHASES="foo_src_unpack
>>>>       bar_src_install"
>>>
>>> You have my strong opposition on such change as well. It will turn
>>> ebuilds into unreadable and undpredictable mess, please do not do that
>>>
>>
>> I'm not sure I follow your complaint.  He is talking about adding one
>> line to an ebuild.  I'm not sure how that is unreadable, and the
>> algorithm you quoted looks fairly predictable to me as well.
>>
>> Certainly it is less convenient than not having to do anything to pull
>> in eclass-defined phase functions, and it requires ebuilds to be
>> updated when eclasses are updated to add new phase functions.  That
>> could be problematic for cases like KDE/X11/etc where you have a large
>> collection of short ebuilds with all the logic in an eclass.
>>
>> I just want to make sure I'm understanding your concern in case there
>> is a new issue being raised.
>
> What's bad with overriding needed functions and saying which exported
> functions(from eclasses) to execute and in which order?
>
> Is this approach flaw? In which ways?

Ok, I was misunderstanding your original comment.  You're advocating
just having ebuilds explicitly call phase functions from eclasses
then, and not automatically inheriting them?  Your objection was to
the ECLASS_PHASES concept, and not to the principle of eliminating
automatic inheritance of phase functions?

Please let me know if I'm still misunderstanding you.  There are a lot
of potential ways to go with this so it isn't always clear what part
of a proposal is being objected to.

Rich