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

[Jens Rehsack]

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

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.

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.

>> 
>>> 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. That's why 04d5d0bf4 eliminates that to reach a reliable
bootstrap path.

> 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

-------------- 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/20160111/2fe03ea0/attachment-0002.sig>