From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.67) (envelope-from ) id 1IIGD6-0001K7-Vx for garchives@archives.gentoo.org; Tue, 07 Aug 2007 03:58:21 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l773vRE3005695; Tue, 7 Aug 2007 03:57:27 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l773tcB3003448 for ; Tue, 7 Aug 2007 03:55:38 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id CDF9B652F7 for ; Tue, 7 Aug 2007 03:55:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: 1.275 X-Spam-Level: * X-Spam-Status: No, score=1.275 required=5.5 tests=[AWL=-1.466, BAYES_50=0.001, RCVD_NUMERIC_HELO=1.5, SARE_LWSHORTT=1.24] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogcDhEmKZGBu for ; Tue, 7 Aug 2007 03:55:36 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id DA9A965278 for ; Tue, 7 Aug 2007 03:55:35 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IIGAK-0004nT-76 for gentoo-dev@gentoo.org; Tue, 07 Aug 2007 05:55:28 +0200 Received: from 82.152.209.191 ([82.152.209.191]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Aug 2007 05:55:28 +0200 Received: from slong by 82.152.209.191 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Aug 2007 05:55:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steve Long Subject: [gentoo-dev] Re: Re: Hooks are gone from java eclasses Date: Tue, 07 Aug 2007 04:55:54 +0100 Message-ID: References: <46B5885F.1070203@gentoo.org> <46B74970.80008@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 82.152.209.191 User-Agent: KNode/0.10.4 Sender: news Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by robin.gentoo.org id l773vRFu005695 X-Archives-Salt: 9b0bd872-22bc-44f6-9dd9-8c69a557e51e X-Archives-Hash: 96371610ca3a1a9473adfd6f4ebdfdd8 Petteri R=E4ty wrote: > Steve Long kirjoitti: >> Petteri R=E4ty wrote: >>> http://bugs.gentoo.org/show_bug.cgi?id=3D163262 >>> >> What is the situation regarding the hooks in general? > A user feature as said in the bug. >=20 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 el= se >>>> 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. >>> >> >>> 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? >> >=20 > 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 talki= ng about proposing stuff for EAPI=3D1, just enquiring about the general stat= e of hooks since there didn't seem to be a clear consensus from the bug. >>=20 >> (I'm thinking along the lines of an eclass which defines foo_src_unpac= k >> which can be called by an ebuild function if overridden.) >>=20 >=20 > Which would be how eclasses already work. >=20 Yes, that was my point: why is that not appropriate for this set of functions? --=20 gentoo-dev@gentoo.org mailing list