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? -- [EMAIL PROTECTED] mailing list
