Mailing List Archive

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.

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

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

http://archives.gentoo.org/stats/gentoo-dev-per-month.xml

Feel free to contact me off list if you have any more questions instead
of adding traffic to the mailing list.

Regards,
Petteri

Steve Long kirjoitti:
> 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.
>

Yes. A user feature for EAPI-0, nothing more. So if you know what they
are why ask here?

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

Yep you don't see it but don't you wonder that you are the only one
responding to this thread? The hooks can't and will not be part of
EAPI-0 because it's not backwards ABI compatible.

http://bugs.gentoo.org/show_bug.cgi?id=163262#c11

"Short version; it's valid- I specifically gave them the go ahead till
the underlying issues (not their fault) were fixed."

The underlying issues are now fixed so the hooks are gone.

>>> (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?
>

Doesn't make it backwards ABI compatible. What part of the I am happy to
explain this stuff in more detail off list didn't you understand?

Regards,
Petteri

Petteri Räty wrote:
> http://bugs.gentoo.org/show_bug.cgi?id=163262
>
What is the situation regarding the hooks in general?

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

(I'm thinking along the lines of an eclass which defines foo_src_unpack
which can be called by an ebuild function if overridden.)


--
gentoo-dev@gentoo.org mailing list

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@gentoo.org mailing list