[gentoo-dev] Re: Re: Hooks are gone from java eclasses

[Steve Long]

Petteri Räty wrote:
> Steve Long kirjoitti:
>> Petteri Räty wrote:
>>> http://bugs.gentoo.org/show_bug.cgi?id=163262
>>>
>> What is the situation regarding the hooks in general?
> A user feature as said in the bug.
>
What, you mean the bit I quoted? I am well aware it's a "user feature,"
surprisingly enough.

>>>> They're a horrible solution. They don't stack and they override
>>>> something that is used by users. What's going to happen if anyone else
>>>> starts using the same functions?
>>> It's primarily a user feature, introduced due to the usefulness of
>>> /etc/portage/bashrc breaking down with proper env state handling.
>>>
>> <snip>
>>> If paludis doesn't want to support (pre|post)_*, whatever, long term it
>>> was only a user feature.
>>>
>>> Short term, it's part of the required env support.
>>>
>> The "only a user feature" bothers me tbh. Is it so hard to make the
>> functions stack then?
>>
>
> Hard or not, read and understand what the whole EAPI stuff is about.
> Feel free to propose stuff for EAPI-1 but to do that you should be able
> to grasp what is useful and what is not. For that one should have lots
> of ebuild writing experience.
>
That's nice; I really don't see the relevance. The question was: why can't
this be implemented in a sane (ie stackable) fashion? I wasn't even talking
about proposing stuff for EAPI=1, just enquiring about the general state of
hooks since there didn't seem to be a clear consensus from the bug.

>>
>> (I'm thinking along the lines of an eclass which defines foo_src_unpack
>> which can be called by an ebuild function if overridden.)
>>
>
> Which would be how eclasses already work.
>
Yes, that was my point: why is that not appropriate for this set of
functions?


-- 
gentoo-dev@g.o mailing list