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.60) (envelope-from ) id 1GQ8ul-00040F-Pj for garchives@archives.gentoo.org; Wed, 20 Sep 2006 20:43:28 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.6) with SMTP id k8KKVfPG022910; Wed, 20 Sep 2006 20:31:41 GMT Received: from slimak.dkm.cz (slimak.dkm.cz [62.24.64.34]) by robin.gentoo.org (8.13.8/8.13.6) with SMTP id k8KKVeFU003457 for ; Wed, 20 Sep 2006 20:31:40 GMT Received: (qmail 30839 invoked by uid 0); 20 Sep 2006 20:31:39 -0000 Received: from r141.net.upc.cz (HELO ?192.168.1.1?) (62.24.83.141) by slimak.dkm.cz with SMTP; 20 Sep 2006 20:31:39 -0000 Message-ID: <4511A52B.2010700@gentoo.org> Date: Wed, 20 Sep 2006 22:31:39 +0200 From: Vlastimil Babka User-Agent: Thunderbird 1.5.0.7 (X11/20060917) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-java@gentoo.org MIME-Version: 1.0 To: gentoo-java@lists.gentoo.org Subject: Re: [gentoo-java] generation-2 java eclass References: <200609152007.32247.alon.barlev@gmail.com> <450C8B52.8050707@gentoo.org> <200609201307.51119.alon.barlev@gmail.com> In-Reply-To: <200609201307.51119.alon.barlev@gmail.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 1461a080-a5f7-42ee-ab07-ba98cf9db789 X-Archives-Hash: 2d6fe79a42ee72b5b68ef5b8c0768b0f Alon Bar-Lev wrote: > Thanks for explaining that. > >>> 2. It seems a bit strange that two eclasses can override the same >>> function name... How such conflict is resolved? >> Order of inheriting matters, the latter eclass overrides the >> former. Ebuild inheriting conflicting eclasses should then override >> the function itself and call the functions of both eclasses from >> there. Now if there was a repoman check for that... > > Right... But since, as you said, the elcass should not use the pre > stuff, it should not be a problem. Maybe you're confusing pre_hooks with usual function overriding done via EXPORT_FUNCTIONS (see eclass howto). I just explained the EXPORT overriding. For conflicting pre_hooks, I was only told that user defined hook beats eclass. >>> 3. Looking at java-pkg-2.eclass I see function name >>> pre_pkg-2_setup, shouldn't it be pre_pkg_setup? I see that >>> pre_pkg_setup is specified in java-pkg-opt-2.eclass... Why is >>> there a difference? >> Must be a typo. As a result, java env is probably not set properly >> inside ebuild's pkg_setup() (for ebuilds that define it). But since >> there are correct hooks for other phases (especially src_compile) >> it didn't cause any harm so far. > > Should I open a bug for it, or you can fix it? I can fix it but I just found out that portage seems to ignore pre_pkg_setup() hook anyway. Will need to talk to portage people if that's feature or bug. > >>> 4. Can you please fix the documentation of java development and >>> on the eclass it-self so that there will be a comment that the >>> unlike other eclasses, java-pkg*-2_pkg_setup should not be called >>> from pkg_setup? >> Well, since the usage of phase hooks is only a workaround (not >> meant to free ebuild writer from calling java-pkg*-2_pkg_setup, >> that's just a consequence) I would say it's better to document that >> it should be called from ebuild explicitly, so when we stop using >> the phase hooks (and maybe it's time already?), number of ebuilds >> won't get broken instantly. > > Right, I think so too. > So people should be told to call the pkg_setup. > > For example openoffice ebuild removed the call to > java-pkg*-2_pkg_setup since it is already called. > History is on bug#139340. > For now we decided to rely on the phase hooks (as nichoj told me), so no need to call pkg_setup. The hooks behaviour in portage can even change so that they will stack and not override, means we might stay with them. Not decided yet, so no rush to go fix ebuilds that work with current setup. -- Vlastimil Babka (Caster) Gentoo/Java -- gentoo-java@gentoo.org mailing list