What's the expected set of OpenJDK packages in Fedora 29?
I see three version:
java-openjdk-headless-11.0.1.13-8.rolling.fc29.x86_64 java-11-openjdk-headless-11.0.1.13-4.fc29.x86_64 java-1.8.0-openjdk-headless-1.8.0.191.b12-11.fc29.x86_64
Surely we do not need two versions of OpenJDK 11?
And I think it was possible to install LibreOffice without OpenJDK 8. With the current updates/updates-testing composes, this no longer appears to be possible. Is this a deliberate change?
Thanks, Florian
On Mon, 2018-12-17 at 13:22 +0100, Florian Weimer wrote:
What's the expected set of OpenJDK packages in Fedora 29?
I see three version:
java-openjdk-headless-11.0.1.13-8.rolling.fc29.x86_64 java-11-openjdk-headless-11.0.1.13-4.fc29.x86_64 java-1.8.0-openjdk-headless-1.8.0.191.b12-11.fc29.x86_64
This looks right.
Surely we do not need two versions of OpenJDK 11?
Package java-openjdk is tracking the latest GA'ed version of OpenJDK. Right now that's JDK 11. Coincidentally, this is also an LTS version which is packaged elsewhere (java-11-openjdk). java-openjdk will be JDK 12 once it's GA in spring 2019. This situation will re-occur once an LTS version is also the latest GA'ed JDK.
It's a weird construct, but we don't have good alternatives for a rolling release package:
A) JDK 10 is already EOL, JDK 12 isn't GA'ed yet, so not really suitable for a stable Fedora release. B) Retiring the package, then unretiring it when it's no longer matching an LTS release seems sub-optimal user experience. C) Virtually providing it isn't possible, without breakages. Not all JDK packages are ready for JDK 9+. If java-11-openjdk virtually provided java-openjdk-headless it might break apps.
Given the above, we've opted for this solution.
And I think it was possible to install LibreOffice without OpenJDK 8. With the current updates/updates-testing composes, this no longer appears to be possible. Is this a deliberate change?
Do you know which package drags in OpenJDK 8? IIRC, libreoffice-ure has a require on 'libjvm.so()'[1]. The plan is to only provide it for the main JDK in Fedora (currently JDK 8). The reason is the same as above. Not all projects are ready for JDK 9+ (or 11).
HTH, Severin
* Severin Gehwolf:
On Mon, 2018-12-17 at 13:22 +0100, Florian Weimer wrote:
What's the expected set of OpenJDK packages in Fedora 29?
I see three version:
java-openjdk-headless-11.0.1.13-8.rolling.fc29.x86_64 java-11-openjdk-headless-11.0.1.13-4.fc29.x86_64 java-1.8.0-openjdk-headless-1.8.0.191.b12-11.fc29.x86_64
This looks right.
Surely we do not need two versions of OpenJDK 11?
Package java-openjdk is tracking the latest GA'ed version of OpenJDK. Right now that's JDK 11. Coincidentally, this is also an LTS version which is packaged elsewhere (java-11-openjdk). java-openjdk will be JDK 12 once it's GA in spring 2019. This situation will re-occur once an LTS version is also the latest GA'ed JDK.
It's a weird construct, but we don't have good alternatives for a rolling release package:
A) JDK 10 is already EOL, JDK 12 isn't GA'ed yet, so not really suitable for a stable Fedora release. B) Retiring the package, then unretiring it when it's no longer C) Virtually providing it isn't possible, without breakages. Not all JDK packages are ready for JDK 9+. If java-11-openjdk virtually provided java-openjdk-headless it might break apps.
Surely the java-openjdk packages could be empty and just depend on the java-11-openjdk packages for now?
And I think it was possible to install LibreOffice without OpenJDK 8. With the current updates/updates-testing composes, this no longer appears to be possible. Is this a deliberate change?
Do you know which package drags in OpenJDK 8? IIRC, libreoffice-ure has a require on 'libjvm.so()'[1]. The plan is to only provide it for the main JDK in Fedora (currently JDK 8). The reason is the same as above. Not all projects are ready for JDK 9+ (or 11).
I think the root cause is that javapackages-tools-5.3.0-1.fc29 depends on java-1.8.0-openjdk-headless.
Thanks, Florian
On Mon, 2018-12-17 at 14:19 +0100, Florian Weimer wrote:
I think the root cause is that javapackages-tools-5.3.0-1.fc29 depends on java-1.8.0-openjdk-headless.
Yes, that won't change AFAIK. It got introduced with [1]. Question is which package drags in full javapackages-tools, over javapackages- filesystem.
Thanks, Severin
[1] https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_jav...
* Severin Gehwolf:
On Mon, 2018-12-17 at 14:19 +0100, Florian Weimer wrote:
I think the root cause is that javapackages-tools-5.3.0-1.fc29 depends on java-1.8.0-openjdk-headless.
Yes, that won't change AFAIK. It got introduced with [1]. Question is which package drags in full javapackages-tools, over javapackages- filesystem.
I see a dependency in apache-commons-logging-1.2-14.fc29.noarch.rpm. Is this a bug?
Thanks, Florian
On Mon, 2018-12-17 at 15:04 +0100, Florian Weimer wrote:
- Severin Gehwolf:
On Mon, 2018-12-17 at 14:19 +0100, Florian Weimer wrote:
I think the root cause is that javapackages-tools-5.3.0-1.fc29 depends on java-1.8.0-openjdk-headless.
Yes, that won't change AFAIK. It got introduced with [1]. Question is which package drags in full javapackages-tools, over javapackages- filesystem.
I see a dependency in apache-commons-logging-1.2-14.fc29.noarch.rpm. Is this a bug?
Maybe. At the time, the automatic java requires generator generated requires on javapackages-tools and not javapackages-filesystem. This has changed[2]. Perhaps this package didn't get rebuilt after and missed the update.
Thanks, Severin
* Severin Gehwolf:
On Mon, 2018-12-17 at 15:04 +0100, Florian Weimer wrote:
- Severin Gehwolf:
On Mon, 2018-12-17 at 14:19 +0100, Florian Weimer wrote:
I think the root cause is that javapackages-tools-5.3.0-1.fc29 depends on java-1.8.0-openjdk-headless.
Yes, that won't change AFAIK. It got introduced with [1]. Question is which package drags in full javapackages-tools, over javapackages- filesystem.
I see a dependency in apache-commons-logging-1.2-14.fc29.noarch.rpm. Is this a bug?
Maybe. At the time, the automatic java requires generator generated requires on javapackages-tools and not javapackages-filesystem. This has changed[2]. Perhaps this package didn't get rebuilt after and missed the update.
Thanks. I verified that the dependency changes in a rebuild and filed:
https://bugzilla.redhat.com/show_bug.cgi?id=1660117
Florian
On Mon, 2018-12-17 at 15:31 +0100, Florian Weimer wrote:
- Severin Gehwolf:
On Mon, 2018-12-17 at 15:04 +0100, Florian Weimer wrote:
- Severin Gehwolf:
On Mon, 2018-12-17 at 14:19 +0100, Florian Weimer wrote:
I think the root cause is that javapackages-tools-5.3.0-1.fc29 depends on java-1.8.0-openjdk-headless.
Yes, that won't change AFAIK. It got introduced with [1]. Question is which package drags in full javapackages-tools, over javapackages- filesystem.
I see a dependency in apache-commons-logging-1.2-14.fc29.noarch.rpm. Is this a bug?
Maybe. At the time, the automatic java requires generator generated requires on javapackages-tools and not javapackages-filesystem. This has changed[2]. Perhaps this package didn't get rebuilt after and missed the update.
Thanks. I verified that the dependency changes in a rebuild and filed:
OK. Just be aware that the main JDK in Fedora is still 8 and all other packaged JDK versions won't have lib*.so internal provides, version- less java-headless/java-devel provides etc. until we are more confident that projects have migrated to support modular JDKs.
This issue with libreoffice-ure and multiple JDKs being pulled in via RPM might come back :-/
Cheers, Severin
On Mon, 2018-12-17 at 14:19 +0100, Florian Weimer wrote:
- Severin Gehwolf:
On Mon, 2018-12-17 at 13:22 +0100, Florian Weimer wrote:
What's the expected set of OpenJDK packages in Fedora 29?
I see three version:
java-openjdk-headless-11.0.1.13-8.rolling.fc29.x86_64 java-11-openjdk-headless-11.0.1.13-4.fc29.x86_64 java-1.8.0-openjdk-headless-1.8.0.191.b12-11.fc29.x86_64
This looks right.
Surely we do not need two versions of OpenJDK 11?
Package java-openjdk is tracking the latest GA'ed version of OpenJDK. Right now that's JDK 11. Coincidentally, this is also an LTS version which is packaged elsewhere (java-11-openjdk). java-openjdk will be JDK 12 once it's GA in spring 2019. This situation will re-occur once an LTS version is also the latest GA'ed JDK.
It's a weird construct, but we don't have good alternatives for a rolling release package:
A) JDK 10 is already EOL, JDK 12 isn't GA'ed yet, so not really suitable for a stable Fedora release. B) Retiring the package, then unretiring it when it's no longer C) Virtually providing it isn't possible, without breakages. Not all JDK packages are ready for JDK 9+. If java-11-openjdk virtually provided java-openjdk-headless it might break apps.
Surely the java-openjdk packages could be empty and just depend on the java-11-openjdk packages for now?
Right. With that we end up adding JDK packages to user's system over time as we cannot obsolete java-11-openjdk packages once java-openjdk is version 12. JDK 11 would still be supported and obsoleting it might not be what users expect. Consider these examples:
Currently for java-openjdk: JDK 10 -> JDK 11 -> JDK 12
java-openjdk temp-dependent on java-11-openjdk: JDK 10 -> JDK 11 -> JDK 11 + JDK 12
Either way, no solution seems ideal. Given that the time window, when this happens, is rather small and users actually using the rolling release package being small too, it seemed a reasonable compromise.
Thanks, Severin
* Severin Gehwolf:
Right. With that we end up adding JDK packages to user's system over time as we cannot obsolete java-11-openjdk packages once java-openjdk is version 12. JDK 11 would still be supported and obsoleting it might not be what users expect. Consider these examples:
Currently for java-openjdk: JDK 10 -> JDK 11 -> JDK 12
java-openjdk temp-dependent on java-11-openjdk: JDK 10 -> JDK 11 -> JDK 11 + JDK 12
Either way, no solution seems ideal. Given that the time window, when this happens, is rather small and users actually using the rolling release package being small too, it seemed a reasonable compromise.
Hmm. I see.
But java-openjdk-headless does not provide java-headless, so you end up with both sets of packages anyway with the current solution, which is far from ideal.
Thanks, Florian
java-devel@lists.fedoraproject.org
-
Florian Weimer -
Severin Gehwolf