[oe] [meta-java][PATCH 0/2] openjdk-8-native: fix do_install and PROVIDES

Tue Jan 12 02:50:42 UTC 2016

> -----Original Message-----
> From: openembedded-devel-bounces at lists.openembedded.org [mailto:openembedded-devel-
> bounces at lists.openembedded.org] On Behalf Of Jens Rehsack
> Sent: Monday, January 11, 2016 6:02 PM
> To: openembedded-devel at lists.openembedded.org
> Subject: Re: [oe] [meta-java][PATCH 0/2] openjdk-8-native: fix do_install and PROVIDES
> 
> 
> > Am 09.01.2016 um 15:22 schrieb Huang, Jie (Jackie) <Jackie.Huang at windriver.com>:
> >
> >
> >
> >> -----Original Message-----
> >> From: openembedded-devel-bounces at lists.openembedded.org [mailto:openembedded-devel-
> >> bounces at lists.openembedded.org] On Behalf Of Jens Rehsack
> >> Sent: Friday, January 08, 2016 5:46 PM
> >> To: openembedded-devel at lists.openembedded.org
> >> Subject: Re: [oe] [meta-java][PATCH 0/2] openjdk-8-native: fix do_install and PROVIDES
> >>
> >>
> >>> Am 07.01.2016 um 04:00 schrieb Huang, Jie (Jackie) <Jackie.Huang at windriver.com>:
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: openembedded-devel-bounces at lists.openembedded.org [mailto:openembedded-
> devel-
> >>>> bounces at lists.openembedded.org] On Behalf Of Jens Rehsack
> >>>> Sent: Wednesday, January 06, 2016 9:57 PM
> >>>> To: openembedded-devel at lists.openembedded.org
> >>>> Subject: Re: [oe] [meta-java][PATCH 0/2] openjdk-8-native: fix do_install and PROVIDES
> >>>>
> >>>>
> >>>>> Am 06.01.2016 um 08:03 schrieb Huang, Jie (Jackie) <Jackie.Huang at windriver.com>:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: openembedded-devel-bounces at lists.openembedded.org [mailto:openembedded-
> >> devel-
> >>>>>> bounces at lists.openembedded.org] On Behalf Of Jens Rehsack
> >>>>>> Sent: Tuesday, January 05, 2016 3:21 AM
> >>>>>> To: openembedded-devel at lists.openembedded.org
> >>>>>> Subject: Re: [oe] [meta-java][PATCH 0/2] openjdk-8-native: fix do_install and PROVIDES
> >>>>>>
> >>>>>> It's insane re-introducing a virtual/javac-native without understanding
> >>>>>> the issues coming with that.
> >>>>>
> >>>>> Please carefully review the patches before saying insane, I don't think it was
> >>>>> correct to remove virtual/javac-native since there are several providers.
> >>>>
> >>>> What does virtual/javac-native mean? Correctly, there can be several providers.
> >>>>
> >>>> How many of them can you have in one sysroot/build? One.
> >>>>
> >>>> So - when in an openjdk-7 or openjdk-8 bootstrap 4 recipes PROVIDE virtual/javac-native,
> >>>> what happens?
> >>>
> >>> So seem like you don't really understand how it should be used.
> >>>
> >>> Yes, only one we can have when there are multiple providers, that's why we should
> >>> use PREFERRED_PROVIDER to determines which one it is, and use the virtual/foo
> >>> instead of specific provider's name in DEPENDS/RDEPENDS of the recipe that requires it,
> >>> so we can ensure only one will be built and avoid conflicts.
> >>
> >> And there starts your misunderstanding:
> >
> > Ok, if so, sorry that my English is not good enough to understand your words correctly.
> 
> Take a number ;)
> 
> >> You can't even install multiple providers, even when picking one.
> >
> > Picking one is to avoid installing multiple providers, why do we need to install
> > multiple providers? Seems likely I'm starting to misunderstand again?
> 
> This isn't optional!

Ok, I see why  we don't have the same understanding.

We have different definition of providers:
You mean every packages that have java/javac binary installed as providers regardless of the different installed locations.
Mine is based on the definition of PROVIDES, only those intall java/javac in the same location and explicitly define
in PROVIDES variable:

For example:
Cacao-native and jamvm-native both install java in /usr/bin and define virtual/java-native in PROVIDES,
So they are providers of virtual/java-native;
icedtea7-native installs java in /usr/lib/jvm/icedtea7-native/bin/, it's not provider of virtual/java-native here.

> 
> openjdk-7-native (provided by icedtea7) requires Java5 to build (provided by ecj-initial, iirc).
> openjdk-7 requires openjdk-7-native - so at least here you have 2 providers for java-native in your
> sysroot/x86_64 ...
> 
> openjdk-8-native requires Java7 or Java8 to build, which is provided by icedtea7 or a previous build of
> openjdk-8-native (for reliability I let openjdk-8-native depend on icedtea7).
> openjdk-8 requires Java7 or Java8 to build (icedtea7-native or openjdk-8-native), for reliability I let
> openjdk-8 depend on openjdk-8-native.

I surely knew this, that's why I removed the symlink and PROVIDES, here is the comments in my fix:
    - Do not let openjdk-8-native provides jar, java and javac,
      just like what we do in icedtea7-native, which can provides
      but not to avoid circular dependencies and conflicts.

> 
> Bootstrapping Java7 means, you have 3 javac and 3 javavm's in you native sysroot (jikes, ecj-initial,
> icedtea7), bootstrapping openjdk-8 adds openjdk-8-native.
> 
> >> But doesn't icedtea7-native provide virtual/java-native and virtual/javac-native?
> >> Doesn't openjdk-8-native provide virtual/java-native and virtual/javac-native?
> >>
> >> When virtual/java-native is only for bootstrapping, that it's misused and
> >> must be removed. Providers are for abstraction, not for confusing.
> >
> > I think you mean that there are two java: one for bootstrapping and another is normal java,
> > So maybe you need something like virtual/java-bootstrap-native and virtual/java-native to
> > avoid confusing.
> > For now, the followings can provide java:
> > cacao-native, jamvm-native, icedtea7-native, openjdk8-native
> >
> > which ones are for bootstrapping only?
> 
> Depends what you want to bootstrap ;)
> That's why the virtual/java*-native is such annoying.

I don't think it's annoying. It depends how you define it, just like I said, you can clearly define
something like virtual/java-bootstrap-native and others to avoid confusing.

> 
> >>
> >>> FYI:
> >>> http://www.yoctoproject.org/docs/2.0/bitbake-user-manual/bitbake-user-manual.html#bb-
> >> bitbake-preferences
> >>> http://www.yoctoproject.org/docs/2.0/ref-manual/ref-manual.html#var-PREFERRED_PROVIDER
> >>>
> >>>>
> >>>> It is insane to have multiple providers for the same virtual/foo when at least a bunch
> >>>
> >>> Virtual/foo and PREFERRED_PROVIDER is one of the mechanisms to handle multiple providers,
> >>> (another one is update-alternatives which is not supported by -native recipe), and work fine
> >>> in many projects, why is it insane here?
> >>
> >> Insane is, that you cannot choose - you have to install all until you reach the required
> >> Java language level.
> >
> > Again, I may misunderstand, I don't know why I have to install all (providers?)?
> >
> >>
> >>> I tested my patches to build openjdk7, openjdk8 and most recipes in meta-java with and without
> >> sstate
> >>> on qemux86-64, qemuarm, qemuppc and some of our BSPs and they all built fine (previous
> method
> >>> fails to build openjdk7 sometime and always fail when build with sstate)
> >>
> >> That has nothing to do with the providers, it has to do with the wrong install of same
> >> binary to a place where another one has been installed. This has to do with alternatives,
> >
> > I agree that the alternatives may be a better solution than providers, but the problem is the
> > update-alternative.bbclass doesn't support -native packages, please send patch to fix it if you
> > think it's needed.
> 
> And provides is the wrong logic.

I don't think it's wrong, you just need a clearer definition.

> That's why 04d5d0bf4 eliminates that to reach a reliable
> bootstrap path.

But this introduced conflicts(along with the incorrect do_install of openjdk8-native) and it always
fail when build with sstate.

Thanks,
Jackie

> 
> > Anyway, these patches have been merged and it works fine for now in our project, no insane error
> > happens. Feel free to send your patch to fix the insane part you think,
> 
> But you patch and the way you pushed it makes it impossible for me to share work based on that,
> since I don't go and revert your reverts to wait for the next moment you don't get it and override
> it again. As long as you stick on your idea, feel free to cherry-pick recipes I build on meta-java
> or cross-compiled java from my github repositories.
> 
> > but please remember to do
> > enough tests to ensure it doesn't break others. Thanks!
> 
> I tested as good as I could in my environment and asked for more than 4 weeks people on ML to test.
> When you work on master, expect some breaking. No hurry insane revert needed.
> 
> Best regards
> --
> Jens Rehsack - rehsack at gmail.com