Expected OpenJDK packages in Fedora 29

[Florian Weimer]

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

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

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1590796#c14

[Florian Weimer]

* 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

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

Thanks,
Severin

[1]
https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_...

[Severin Gehwolf]

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

[Florian Weimer]

* 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

[Florian Weimer]

* 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

[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,
Severin

[2] https://bugzilla.redhat.com/show_bug.cgi?id=1600426#c12

[Florian Weimer]

* 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

[Severin Gehwolf]

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:
>  
>    <https://bugzilla.redhat.com/show_bug.cgi?id=1660117> 
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