Bug 1500288 - javapackages-tools: Split javapackages-filesystem to a subpackage
Summary: javapackages-tools: Split javapackages-filesystem to a subpackage
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: javapackages-tools
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Mikolaj Izdebski
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1508822 1622207 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-10-10 10:46 UTC by jiri vanek
Modified: 2018-11-30 23:10 UTC (History)
15 users (show)

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:
Clone Of:
Environment:
Last Closed: 2018-11-30 23:10:02 UTC


Attachments (Terms of Use)

Description jiri vanek 2017-10-10 10:46:53 UTC
Description of problem:
jpackage utils requires java-1.8.0-openjdk


Version-Release number of selected component (if applicable):
f27+


How reproducible:
Consider system java settings for f27:
 https://fedoraproject.org/wiki/Releases/27/ChangeSet#Decouple_system_java_setting_from_java_command_setting

Which brought java-1.8.0-openjdk as dependence to jpackage-tools.

As side effect
 - java-1.8.0-openjdk and jpackage-tools are now  circular dependences.
 - java-1.8.0-openjdk-aarch32 now pulls in java-1.8.0-openjdk
   - that successfully kills usage of java-1.8.0-openjdk-aarch32 in buildroot, as you can not change alternatives

Now consider jdk9 in f27:
 https://fedoraproject.org/wiki/Releases/27/ChangeSet#Java_9

the side kick is same as for jdk8-aarch32. Installation of  java-9-openjdk (which rewuires jpackage tools) will pull in java8. It kills jdk9 in buildroot, and making the life of possible jdk9 user very uncomfortable.


Actual results:
Installation of jdk8-aarch32 or jdk9 is bringing jdk8 as transitional dependence.


Expected results:
Installation of jdk8-aarch32 or jdk9 will not bring jdk8 as transitional dependence.

Comment 1 Michael Simacek 2017-10-13 08:05:08 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.

Comment 2 jiri vanek 2017-10-13 08:44:12 UTC
(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.

Comment 3 Michael Simacek 2017-10-13 09:38:28 UTC
(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.

Comment 4 jiri vanek 2017-10-16 12:44:46 UTC
(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.

Comment 5 Severin Gehwolf 2017-11-02 10:25:45 UTC
*** Bug 1508822 has been marked as a duplicate of this bug. ***

Comment 6 Bjarte Stien Karlsen 2018-05-16 19:10:48 UTC
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.

Comment 7 Mikolaj Izdebski 2018-05-16 19:37:31 UTC
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

Comment 8 Severin Gehwolf 2018-05-17 08:44:01 UTC
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.

Comment 11 Severin Gehwolf 2018-05-17 14:12:17 UTC
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

Comment 13 Orion Poplawski 2018-07-26 15:56:11 UTC
Is this going to get moved to Fedora 28 as well?

Comment 14 Mikolaj Izdebski 2018-07-27 07:23:24 UTC
(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.

Comment 15 Orion Poplawski 2018-07-27 15:19:37 UTC
At the moment, no.  Just curious.

Comment 16 jiri vanek 2018-07-30 08:22:03 UTC
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)

Comment 17 Mikolaj Izdebski 2018-07-30 09:55:16 UTC
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.

Comment 18 jiri vanek 2018-07-30 14:23:15 UTC
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!

Comment 19 Mikolaj Izdebski 2018-07-30 14:28:14 UTC
"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.

Comment 20 Severin Gehwolf 2018-09-17 08:05:41 UTC
*** Bug 1622207 has been marked as a duplicate of this bug. ***

Comment 21 Ben Cotton 2018-11-27 14:06:22 UTC
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.

Comment 22 Ben Cotton 2018-11-30 23:10:02 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.