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

[Huang, Jie (Jackie)]

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

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

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

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

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 please remember to do
enough tests to ensure it doesn't break others. Thanks!

Thanks,
Jackie

> not providers.
> 
> Cheers
> --
> Jens Rehsack - rehsack at gmail.com