[gentoo-dev] Hooks are gone from java eclasses

[gentoo-dev] Hooks are gone from java eclasses

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 334 bytes --]

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

Posting to announce because people might not have been able to use the
hooks in their bashrc files because of us using them in our eclasses.
Also if you see some weirdness with Java packages this might be the
cause although the patch was extensively tested.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Steve Long]

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

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

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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