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

[Jens Rehsack]

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

You can't even install multiple providers, even when picking one.
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.

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

> 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,
not providers.

Cheers
--
Jens Rehsack - rehsack at gmail.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20160108/379c7147/attachment-0002.sig>