Bug 1500288
| Summary: | javapackages-tools: Split javapackages-filesystem to a subpackage | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | jiri vanek <jvanek> |
| Component: | javapackages-tools | Assignee: | Mikolaj Izdebski <mizdebsk> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 27 | CC: | akurtako, bjarte, ctubbsii, extras-orphan, java-sig-commits, jerboaa, jvanek, mail, mat.booth, mizdebsk, msrb, myllynen, orion, sgehwolf, sochotni |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | javapackages-tools-5.1.0-1.fc29 java-openjdk-10.0.1.10-5.fc29 java-1.8.0-openjdk-1.8.0.171-6.b10.fc29 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-11-30 23:10:02 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
jiri vanek
2017-10-10 10:46:53 UTC
> It kills .* in buildroot
Can you be more specific? What do you mean by kill?
If some package needs to be built by different JDK than the default one, it can point JAVA_HOME to it.
As for java-1.8.0-openjdk-aarch32, if it should be the default for arm, we can change the Requires for that platform.
(In reply to Michael Simacek from comment #1) > > It kills .* in buildroot > > Can you be more specific? What do you mean by kill? If you require java 9, you expect it would be the only java in buildroot. However, suddnely you have also jdk8 in buildroot, and it will switch alternatives on itself. And alternatives are the only thing we support for changing jdk. You can workaround it by using /usr/lib/jvm/java-9 path, but then you lost simple movability to another jdk. > If some package needs to be built by different JDK than the default one, it > can point JAVA_HOME to it. Can and can not. JAVA_HOME is being discouraged (not only) in fedora for long time. Well heavily used anyway for good reason. > > As for java-1.8.0-openjdk-aarch32, if it should be the default for arm, we > can change the Requires for that platform. I don't know. The aarch32 port is not exactly super stable. And I do not wont to rob user for choice. Well and that is what you did. (In reply to jiri vanek from comment #2) > (In reply to Michael Simacek from comment #1) > > > It kills .* in buildroot > > > > Can you be more specific? What do you mean by kill? > > If you require java 9, you expect it would be the only java in buildroot. That assumes that none of the packages in the transitive closure of your dependencies doesn't require any specific JDK. And jp is not the only package that is doing that. What if a packager of something deep in your dependency chain decides to add Requires: java < 1:9, because his pkg doesn't work with java 9 yet? Relying on absence of a package is fragile. If people want to use non-default JDK, they should make it explicit (by using JAVA_HOME). > However, suddnely you have also jdk8 in buildroot, and it will switch > alternatives on itself. And alternatives are the only thing we support for > changing jdk. > You can workaround it by using /usr/lib/jvm/java-9 path, but then you lost > simple movability to another jdk. > > > If some package needs to be built by different JDK than the default one, it > > can point JAVA_HOME to it. > > Can and can not. JAVA_HOME is being discouraged (not only) in fedora for > long time. Well heavily used anyway for good reason. Discouraged where exactly? By whom? > > > > > As for java-1.8.0-openjdk-aarch32, if it should be the default for arm, we > > can change the Requires for that platform. > > I don't know. The aarch32 port is not exactly super stable. And I do not > wont to rob user for choice. Well and that is what you did. (In reply to Michael Simacek from comment #3) > (In reply to jiri vanek from comment #2) > > (In reply to Michael Simacek from comment #1) > > > > It kills .* in buildroot > > > > > > Can you be more specific? What do you mean by kill? > > > > If you require java 9, you expect it would be the only java in buildroot. > > That assumes that none of the packages in the transitive closure of your > dependencies doesn't require any specific JDK. And jp is not the only But that assumption is 99% correct. There was sucesfull effort to make packages to require jsut "java" > package that is doing that. What if a packager of something deep in your > dependency chain decides to add Requires: java < 1:9, because his pkg > doesn't work with java 9 yet? Relying on absence of a package is fragile. That is slightly different case. If some of my depndencies pulls it in, that its on discussion with maintainer how to make it work. The dependence tree is quite shallow and the most used depndencies are usually most healthy. Unluckily, all java packages requires JP. So by enforcing this here you are affecting them all. Do you mind to stop asking quite unrelated questions and get back to the issue? Would be nice focus why JP are requiring suddenly java-1.8.0-openjdk and mayhem it brought. *** Bug 1508822 has been marked as a duplicate of this bug. *** Is there any progress on this issue? I would like to create a Docker container ussing fedora-minimal with java-10. Currently it also includes java8 because of this issue. Latest version of javapackages (5.1.0) introduced new javapackages-filesystem package [1], which is pretty minimal - it doesn't have any requires, but owns directories into which JDK packages are installed. JDK packages can switch to requiring javapackages-filesystem instead of javapackages-tools to get rid of transitive dependency on JDK 8. [1] https://github.com/fedora-java/javapackages/pull/54 [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=1081978 PRs for java-1.8.0-openjdk (JDK 8) and java-openjdk (JDK 10) to move to javapackages-filesystem: https://src.fedoraproject.org/rpms/java-1.8.0-openjdk/pull-request/7 https://src.fedoraproject.org/rpms/java-openjdk/pull-request/11 Jiri, if they look good to you I'll merge and push builds for rawhide. OK, since Jiri was OK with me merging, I've done so and this should no longer be an issue with java-openjdk-10.0.1.10-5.fc29 and java-1.8.0-openjdk-1.8.0.171-6.b10.fc29. I.e. once these builds complete: JDK 8: https://koji.fedoraproject.org/koji/buildinfo?buildID=1082659 JDK 10: https://koji.fedoraproject.org/koji/buildinfo?buildID=1082663 Is this going to get moved to Fedora 28 as well? (In reply to Orion Poplawski from comment #13) > Is this going to get moved to Fedora 28 as well? No, I was not planning this feature for Fedora 28. Is it important for you to have it? If yes I can reconsider backporting it. At the moment, no. Just curious. I think to have this backported all the way down to f27 will just make everybody more happy and soem nasty misbehaving to disapear (we now have jdk10, 11 and 8 in fedora, so any cyclic dependencies are making real mess) Adding this feature to F27 at this point would be against updates policy, but I can backport it to F28 if there is desire for it. Both f27 and f28 are stable released system. You already have the virtual provides in f27. Imho it is bug in f27, so fixing it is not against rules. In all cases, this is up to you, and notm uch people will be on f27 in next few weeks. Tahnx a lot! "Package maintainers SHOULD: Push only major bug fixes and security fixes to the previous stable releases (i.e., at present, Fedora 27 and before)." This feature is definitely not a "major bugfix" and therefore should not be pushed to Fedora 27. *** Bug 1622207 has been marked as a duplicate of this bug. *** This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |