Description of problem: A clean install of f29 from the beta workstation iso provides JRE 11, not JRE 8: $ java -version openjdk version "11-ea" 2018-09-25 OpenJDK Runtime Environment (build 11-ea+22) OpenJDK 64-Bit Server VM (build 11-ea+22, mixed mode, sharing) Version-Release number of selected component (if applicable): Fedora 29 workstation beta 1.5 Steps to Reproduce: 1. clean install f29 workstation beat 1.5 https://download.fedoraproject.org/pub/fedora/linux/releases/test/29_Beta/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-29_Beta-1.5.iso 2. type "java -version" Actual results: openjdk version "11-ea" 2018-09-25 OpenJDK Runtime Environment (build 11-ea+22) OpenJDK 64-Bit Server VM (build 11-ea+22, mixed mode, sharing) Expected results: (some variant of OpenJDK 1.8) Additional info:
My installation process for f29 was in a VirtualBox VM. I installed from the live ISO, then I may have let the system upgrade itself. I will redo an install without updates and leave a comment here.
I have confirmed that JDK 11 is the installed default on both the f29 beta 1.5 live ISO and the initial install to the hard disk.
Hi Stephen! This is indeed important issue. Not much Fedora stuff will run with JDK11. I'm wondering. How could it happen? How can it be prevented in future? Few notes: It did not happened when we introduced java-openjdk (providing java-10-openjdk in that time). the provides were identical, and composes had correctly jre8. Maybe we introduced JDK10 to late? Jpackagestool, should be the only package depending on exact version of java - https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_java_command_setting - everything else is consuming what jpacagetools give them, unless user changes. If jdk11 is supposed to be on image - eg because it is self contained change, then also jdk8 should be there. If it is there as dependence of any other package, then it is bug. Severe bug, as the program will unlikely work with jdk11. It msot likely mean dependency resolution went mad, or japcakge utils are out of play in some weird case.
I just checked comps.xml, JDK 11 is not present at all. So whatever is happening here must be caused by a dependency pulling it in. Given that java-11-openjdk-headless `Provides: java-headless`, my guess is that the dependency solver is picking it (absent other cues) to satisfy any package that `Requires: java-headless` (which is 3052 packages in the distribution).
(In reply to Stephen Gallagher from comment #4) > Given that java-11-openjdk-headless `Provides: java-headless`, my guess is > that the dependency solver is picking it (absent other cues) to satisfy any > package that `Requires: java-headless` (which is 3052 packages in the > distribution). Right, so that's the bug. Jiri, over to you: java-11-openjdk-headless does not provide java-headless, or anything non-jdk11 specific.
Here's a related issue (or possibly the entire issue): https://pagure.io/pungi-fedora/blob/f29/f/fedora.conf#_174 We are currently telling pungi (the thing that composes fedora) to filter out java-1.8.0-openjdk in all Workstation or Server composes. I'd guess thats leftover from when 1.6 or 1.7 was the stable and 1.8.0 was the alpha. Should we change this to filter 11 and not 8?
(In reply to Andrew Haley from comment #5) > (In reply to Stephen Gallagher from comment #4) > > > Given that java-11-openjdk-headless `Provides: java-headless`, my guess is > > that the dependency solver is picking it (absent other cues) to satisfy any > > package that `Requires: java-headless` (which is 3052 packages in the > > distribution). > > Right, so that's the bug. Jiri, over to you: java-11-openjdk-headless does > not provide java-headless, or anything non-jdk11 specific. I had removed jre+java versionless provides. (In reply to Kevin Fenzi from comment #6) > Here's a related issue (or possibly the entire issue): > > https://pagure.io/pungi-fedora/blob/f29/f/fedora.conf#_174 > > We are currently telling pungi (the thing that composes fedora) to filter > out java-1.8.0-openjdk in all Workstation or Server composes. I'd guess > thats leftover from when 1.6 or 1.7 was the stable and 1.8.0 was the alpha. > Should we change this to filter 11 and not 8? Yes. Jdk8 must remain here, and jdk11 should be for now (several years?) filtered out.(In reply to Stephen Gallagher from comment #4) > I just checked comps.xml, JDK 11 is not present at all. So whatever is > happening here must be caused by a dependency pulling it in. > > Given that java-11-openjdk-headless `Provides: java-headless`, my guess is > that the dependency solver is picking it (absent other cues) to satisfy any > package that `Requires: java-headless` (which is 3052 packages in the > distribution). This should be impossible to happen. jpackage tools are base package for all java packages, and it requires java-1.8.0-openjdk-headless explicitly. So anything requiring java-healdess shold get 1.8.0 as it is already in transaction because of jpackage tools. Althoug it should be fixed by the update I will post asap, I'm really curious how it happened.
java-11-openjdk-11.0.ea.28-8.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-f10566c2e0
java-11-openjdk-11.0.ea.28-8.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-e402b3f75c
java-11-openjdk-11.0.ea.28-8.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c34978a9f4
(In reply to jiri vanek from comment #7) > > Given that java-11-openjdk-headless `Provides: java-headless`, my guess is > > that the dependency solver is picking it (absent other cues) to satisfy any > > package that `Requires: java-headless` (which is 3052 packages in the > > distribution). > > This should be impossible to happen. jpackage tools are base package for all > java packages, and it requires java-1.8.0-openjdk-headless explicitly. So > anything requiring java-healdess shold get 1.8.0 as it is already in > transaction because of jpackage tools. > Althoug it should be fixed by the update I will post asap, I'm really > curious how it happened. This is F29, where the switch to javapackages-filesystem has been done. That is, only if there is any package requiring full javapackages-tools (over -filesystem) would it drag in java-1.8.0-openjdk.
java-11-openjdk-11.0.ea.28-8.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-c34978a9f4
java-11-openjdk-11.0.ea.28-8.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-f10566c2e0
java-11-openjdk-11.0.ea.28-8.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-e402b3f75c
The guilty is libreoffice: [liveuser@localhost-live ~]$ rpm -q --whatrequires java-headless libreoffice-core-6.1.0.3-1.fc29.x86_64 [liveuser@localhost-live ~]$ rpm -qa | grep javapacka javapackages-filesystem-5.3.0-1.fc29.noarch [liveuser@localhost-live ~]$ rpm -q --whatrequires javapackages-filesystem java-11-openjdk-headless-11.0.ea.22-7.fc29.x86_64 [liveuser@localhost-live ~]$ rpm -q --requires javapackages-filesystem-5.3.0-1.fc29.noarch rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 So that is it, we created javapackages-filesystem to avoid cyclic dependency, and there exists package which do not use java as runtime, so it do not depend on javapackages at all. Is there something we wont to change?
(In reply to jiri vanek from comment #15) > The guilty is libreoffice: > [liveuser@localhost-live ~]$ rpm -q --whatrequires java-headless > libreoffice-core-6.1.0.3-1.fc29.x86_64 > [liveuser@localhost-live ~]$ rpm -qa | grep javapacka > javapackages-filesystem-5.3.0-1.fc29.noarch > [liveuser@localhost-live ~]$ rpm -q --whatrequires javapackages-filesystem > java-11-openjdk-headless-11.0.ea.22-7.fc29.x86_64 > [liveuser@localhost-live ~]$ rpm -q --requires > javapackages-filesystem-5.3.0-1.fc29.noarch > rpmlib(CompressedFileNames) <= 3.0.4-1 > rpmlib(FileDigests) <= 4.6.0-1 > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > rpmlib(PayloadIsXz) <= 5.2-1 > > So that is it, we created javapackages-filesystem to avoid cyclic > dependency, and there exists package which do not use java as runtime, so it > do not depend on javapackages at all. > > Is there something we wont to change? What is the cause of the reluctance to do the obvious thing, and realize that jdk11 should not provide java-headless? jdk11 is totally useless for that purpose.
it is not that bad. I would much rather see jdk11 providing java-headless, and jdk8 listed in https://bugzilla.redhat.com/show_bug.cgi?id=1633327#c6 , however it will remove control from java-sig group. Right now, the java-headless provides were removed from jdk11 If libreoffice works with this setup - which I *guess* it does - then it is actually ok to keep it as it is. Isn't it? Any other "normal" jdk package will pull the rest of javapackages and this jdk8, and will use it.
(In reply to jiri vanek from comment #17) > it is not that bad. I would much rather see jdk11 providing java-headless, I know, but you still haven't said *why* you would much rather see jdk11 providing java-headless. This seems completely irrational to me, so I'm asking because I feel that there must be something that I'm failing to understand.
(In reply to Andrew Haley from comment #18) > (In reply to jiri vanek from comment #17) > > it is not that bad. I would much rather see jdk11 providing java-headless, > > I know, but you still haven't said *why* you would much rather see jdk11 > providing java-headless. This seems completely irrational to me, so I'm > asking because I feel that there must be something that I'm failing to > understand. a) Most likely I have much more faith (unjustified) to backward compatibility of jdk11 then you do. Also I have - again most likely unjustified - believe that jdk9+10 are out long enough to stop people using private APIs. b) As the rolling package of java-openjdk have the provides of java-headelss enabled too, I' keep wondering why jdk11 shouldn't do the same. Decoupling system JDK from custom JDK gave us this freedom.
(In reply to jiri vanek from comment #17) > Any other "normal" jdk package > will pull the rest of javapackages and this jdk8, and will use it. Assuming by "pull the rest of javapackages" you mean "a package which depends on full javapackages-tools": Please explain why you think a java package requiring javapackages-tools is "normal" (if you mean the common case by "normal"). I doubt it is. The only reason requiring full javapackages-tools as a java package post F28 is: a) uses jpackage_script macro b) uses some java-functions from /usr/share/java-utils/java-functions There is valid use cases to require neither. E.g. byteman. The java packaging guidelines have been updated to require javapackages-filesystem rather than javapackages-tools: https://fedoraproject.org/wiki/Packaging:Java#BuildRequires_and_Requires
(In reply to Severin Gehwolf from comment #20) > (In reply to jiri vanek from comment #17) > > Any other "normal" jdk package > > will pull the rest of javapackages and this jdk8, and will use it. > > Assuming by "pull the rest of javapackages" you mean "a package which > depends on full javapackages-tools": > > Please explain why you think a java package requiring javapackages-tools is > "normal" (if you mean the common case by "normal"). I doubt it is. The only > reason requiring full javapackages-tools as a java package post F28 is: > > a) uses jpackage_script macro > b) uses some java-functions from /usr/share/java-utils/java-functions Any and-user application being launch via custom script calling main method (via java-functions) > > There is valid use cases to require neither. E.g. byteman. The java Any library is most likely behave in this way, having requirement on java-headless only. So this is valid case. With only nit, that java developer only will install alone library And common user will install end user application, with correct usage of javapackages-tools (?) > packaging guidelines have been updated to require javapackages-filesystem > rather than javapackages-tools: > https://fedoraproject.org/wiki/Packaging:Java#BuildRequires_and_Requires This looks incomplete: Java binary packages or their dependencies MUST have Requires (generated by RPM or manual) on: java-headless or java-headless >= 1:minimal_required_version javapackages-filesystem This is valid for libraries only. End user application, being CLI shold be: java-headless or java-headless >= 1:minimal_required_version javapackages-tools End user application, being GUI shold be: java or java >= 1:minimal_required_version javapackages-tools If you agree, will modify/PR to this page.
(In reply to jiri vanek from comment #21) > (In reply to Severin Gehwolf from comment #20) > > (In reply to jiri vanek from comment #17) > > > Any other "normal" jdk package > > > will pull the rest of javapackages and this jdk8, and will use it. > > > > Assuming by "pull the rest of javapackages" you mean "a package which > > depends on full javapackages-tools": > > > > Please explain why you think a java package requiring javapackages-tools is > > "normal" (if you mean the common case by "normal"). I doubt it is. The only > > reason requiring full javapackages-tools as a java package post F28 is: > > > > a) uses jpackage_script macro > > b) uses some java-functions from /usr/share/java-utils/java-functions > > Any and-user application being launch via custom script calling main method > (via java-functions) That's b) > > > > There is valid use cases to require neither. E.g. byteman. The java > > Any library is most likely behave in this way, having requirement on > java-headless only. > So this is valid case. > With only nit, that java developer only will install alone library > And common user will install end user application, with correct usage of > javapackages-tools (?) If the library uses deps from javapackages-tools it'll have to require javapackages-tools. See this for a list: https://bugzilla.redhat.com/show_bug.cgi?id=1600426#c13 > > packaging guidelines have been updated to require javapackages-filesystem > > rather than javapackages-tools: > > https://fedoraproject.org/wiki/Packaging:Java#BuildRequires_and_Requires > > This looks incomplete: > > Java binary packages or their dependencies MUST have Requires (generated by > RPM or manual) on: > > java-headless or java-headless >= 1:minimal_required_version > javapackages-filesystem > > This is valid for libraries only. > > End user application, being CLI shold be: > java-headless or java-headless >= 1:minimal_required_version > javapackages-tools Counter example: byteman. It has a script from upstream, which doesn't use any javapackages-tools deps. So even though bmsubmit (for example) is CLI, it won't need javapackages-tools. > End user application, being GUI shold be: > java or java >= 1:minimal_required_version > javapackages-tools Why? What's the rationale of mandating to require javapackages-tools for GUI java apps. A GUI app can work perfectly fine without using any java-functions from javapackages-tools (or JDK 8 for that matter). > > If you agree, will modify/PR to this page. Not really, but if you desire to change the guidelines that has to go through the packaging-commitee. See for example this issue for the javapackages-tools => javapackages-filesystem change: https://pagure.io/packaging-committee/issue/781 Note that the idea of packaging guidelines is that they should only cover the absolutely necessary. They are guidelines, not a recipe.
java-11-openjdk-11.0.ea.28-8.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
java-11-openjdk-11.0.ea.28-8.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
java-11-openjdk-11.0.ea.28-8.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.