[gentoo-java] generation-2 java eclass

[gentoo-java] generation-2 java eclass

[Alon Bar-Lev]

Hello,

Maybe you can help answering some questions I have regarding the
generation-2  java eclass.

I've seen that in openoffice ebuild there is no call to
java-pkg-opt-2_pkg_setup fro pkg_setup, the reason is seems to be 
because it is called automatically.

1. Is there any documentation regarding portage phase hooks? I could
not see any reference to this in eclass HOWTO guide.

2. It seems a bit strange that two eclasses can override the same
function name... How such conflict is resolved?

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?

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?

Best Regards,
Alon Bar-Lev
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] generation-2 java eclass

[Vlastimil Babka]

Alon Bar-Lev wrote:
> Hello,
>
> Maybe you can help answering some questions I have regarding the
> generation-2  java eclass.
>
> I've seen that in openoffice ebuild there is no call to
> java-pkg-opt-2_pkg_setup fro pkg_setup, the reason is seems to be 
> because it is called automatically.
>
> 1. Is there any documentation regarding portage phase hooks? I could
> not see any reference to this in eclass HOWTO guide.
>   
It's a new feature of portage 2.1. See 
/usr/share/doc/portage-<ver>/NEWS.gz. Not mentioned in eclass HOWTO 
because it's not meant to be used by eclasses, but by users. Java eclass 
is a exception, but we should stop using it when portage is able to save 
env properly between phases (which should already be now IIRC?). It's 
bad thing that now an user can override our phase hooks with 
/etc/portage/bashrc.
> 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...
> 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.
> 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.

Regards,
Vlastimil Babka

-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] generation-2 java eclass

[Alon Bar-Lev]

On Sunday 17 September 2006 02:40, Vlastimil Babka wrote:
> Alon Bar-Lev wrote:
> > Hello,
> >
> > Maybe you can help answering some questions I have regarding the
> > generation-2  java eclass.
> >
> > I've seen that in openoffice ebuild there is no call to
> > java-pkg-opt-2_pkg_setup fro pkg_setup, the reason is seems to be
> > because it is called automatically.
> >
> > 1. Is there any documentation regarding portage phase hooks? I
> > could not see any reference to this in eclass HOWTO guide.
>
> It's a new feature of portage 2.1. See
> /usr/share/doc/portage-<ver>/NEWS.gz. Not mentioned in eclass HOWTO
> because it's not meant to be used by eclasses, but by users. Java
> eclass is a exception, but we should stop using it when portage is
> able to save env properly between phases (which should already be
> now IIRC?). It's bad thing that now an user can override our phase
> hooks with /etc/portage/bashrc.

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.

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

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

Best Regards,
Alon Bar-Lev.
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] generation-2 java eclass

[Vlastimil Babka]

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

Re: [gentoo-java] generation-2 java eclass

[Vlastimil Babka]

Vlastimil Babka wrote:
>  >> 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.

Sorry, was wrong on this one. Hook works correctly. I've now fixed the 
typo in eclass.

-- 
Vlastimil Babka (Caster)
Gentoo/Java
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] generation-2 java eclass

[Alon Bar-Lev]

On 9/21/06, Vlastimil Babka <caster@gentoo.org> wrote:
> Vlastimil Babka wrote:
> >  >> 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.
>
> Sorry, was wrong on this one. Hook works correctly. I've now fixed the
> typo in eclass.

Thanks.

Looking at bug#146647, why did you remove the java from the IUSE? I
don't think it is a clean to require programmer to define the
JAVA_PKG_OPT_USE before the inherit... Or you need to add a BIG FAT
WARNING at the eclass documentation/description.

And shouldn't the package append the USE fag (IUSE="${IUSE}
${JAVA_PKG_OPT_USE}") instead of replacing it?

And in order to solve the conflict that may introduce when several
eclasses overwrite the pre* functions, shouldn't you EXPORT_FUNCTIONS
them?

Best Regards,
Alon Bar-Lev.
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] generation-2 java eclass

[William L. Thomson Jr.]

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

On Thu, 2006-09-21 at 08:05 +0300, Alon Bar-Lev wrote:
>
> And shouldn't the package append the USE fag (IUSE="${IUSE}

Sweet typo, but FYI and IMHO, it's not PC :) ^^

-- 
William L. Thomson Jr.
Gentoo/Java

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-java] generation-2 java eclass

[Alon Bar-Lev]

On 9/21/06, William L. Thomson Jr. <wltjr@gentoo.org> wrote:
> On Thu, 2006-09-21 at 08:05 +0300, Alon Bar-Lev wrote:
> >
> > And shouldn't the package append the USE fag (IUSE="${IUSE}
>
> Sweet typo, but FYI and IMHO, it's not PC :) ^^

Forgive me for my ignorance...

FYI = For your information.
IMHO = In my humble opinion.
:) = Smile
PC = ????????????
^^ = ?????????????
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] generation-2 java eclass

[Kurt Guenther]

meant to post on-list.

Kurt Guenther wrote:
> just a typo:  flag instead of fag.
>
> I would guess  PC is politically correct and ^^ means look above.
>
>
>
>
> Alon Bar-Lev wrote:
>   
>> On 9/21/06, William L. Thomson Jr. <wltjr@gentoo.org> wrote:
>>     
>>> On Thu, 2006-09-21 at 08:05 +0300, Alon Bar-Lev wrote:
>>>       
>>>> And shouldn't the package append the USE fag (IUSE="${IUSE}
>>>>         
>>> Sweet typo, but FYI and IMHO, it's not PC :) ^^
>>>       
>> Forgive me for my ignorance...
>>
>> FYI = For your information.
>> IMHO = In my humble opinion.
>> :) = Smile
>> PC = ????????????
>> ^^ = ?????????????
>>     
>
>
>   
   
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] generation-2 java eclass

[William L. Thomson Jr.]

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

On Thu, 2006-09-21 at 13:24 -0400, Kurt Guenther wrote:
> meant to post on-list.

List reply problem eh :)

> Kurt Guenther wrote:
> > just a typo:  flag instead of fag.
> >
> > I would guess  PC is politically correct and ^^ means look above.

Yes and yes :) 

-- 
William L. Thomson Jr.
Gentoo/Java

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-java] generation-2 java eclass

[Vlastimil Babka]

Alon Bar-Lev wrote:
> Looking at bug#146647, why did you remove the java from the IUSE? I

Because the eclass provides it already. Ebuild doesn't need to.

> don't think it is a clean to require programmer to define the
> JAVA_PKG_OPT_USE before the inherit... Or you need to add a BIG FAT
> WARNING at the eclass documentation/description.

You're getting it wrong. JAVA_PKG_OPT_USE is just a name for the flag 
that triggers java support. You need to specify it before inherit line 
if you want the flag to be called differently than "java" (the default). 
Not sure if any ebuild ever overrided that, it's just the possibility.

> And shouldn't the package append the USE fag (IUSE="${IUSE}
> ${JAVA_PKG_OPT_USE}") instead of replacing it?

No, portage itself takes care to put eclass-defined and ebuild-defined 
IUSE together.

> And in order to solve the conflict that may introduce when several
> eclasses overwrite the pre* functions, shouldn't you EXPORT_FUNCTIONS
> them?

No, EXPORT_FUNCTIONS is for exporting the phases itself, not phase 
hooks. Both seem to solve conflict in a way that the later 
defined/inherited wins, so in the end you get one phase function and one 
phase hook.

-- 
Vlastimil Babka (Caster)
Gentoo/Java
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] generation-2 java eclass

[Alon Bar-Lev]

On 9/21/06, Vlastimil Babka <caster@gentoo.org> wrote:
> No, EXPORT_FUNCTIONS is for exporting the phases itself, not phase
> hooks. Both seem to solve conflict in a way that the later
> defined/inherited wins, so in the end you get one phase function and one
> phase hook.

Thanks!

But what happens if two eclasses have phase hook?
Both of them should be called, right?
But if one overwrite the other, only the last one will be called.
-- 
gentoo-java@gentoo.org mailing list