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

Fri Jan 15 09:53:01 UTC 2016

> Am 12.01.2016 um 03:50 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: 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.

But what are cacao-native and jamvm-native good for? Bootstrapping, nothing else.
And for bootstrapping it's restricted to cacao-native, isn't it?

However - maybe just the naming of the provide is unlucky chosen, if it will be possible to bootstrap using jamvm-native.
Someone (not me) has to verify that! But then, the provide must be named virtual/bootstrap-java-native.

Beside of the naming, when ALTERNATIVES doesn't work for native, I don't think any native java-vm/javac should install into usr/bin,
always in a sub-directory of /usr/lib/jvm/$(JAVA_HOME) of the specific java-vm/javac.

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

I didn't call that commit insane ;)
Only this one we're talking about :D

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

If there're surely several working providers for virtual/java-bootstrap-native, what is
recipes-core/ecj/ecj-bootstrap-native.bb in that world?

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

It only fails because of the wrong install of openjdk8-native - I still don't see the conflict.
I grepped over all mails you sent in Dec and didn't find any hint what conflicts by hard-coding the
bootstrap phase.

Can you please be more details here, what beside of the incorrect do_install of openjdk8-native
conflicts?

> 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
> 
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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/20160115/6640ce04/attachment-0002.sig>