I think that any change that will break existing users’ use of Fedora should not be approved. Maintaining compatibility is critical to the survival of Linux and Fedora, because once a platform stops caring about the reason Fedora exists (the users), it becomes simply a toy for developers of Fedora.
When a change is made that prevents a user from doing their day to day activities, they will remember that for a long time and likely will abandon the platform. Or, they will hear about the issue and refuse to upgrade, perhaps forever, which will make their lives much harder over time.
One exception to the forgoing is if a change MUST be made to resolve a security issue and the ere NO possible mitigation for the breaking change. This does not appear to be the case here.
Fedora has broken significant use cases in the past with negative results, such as the power management debacle that killed remote/headless servers by powering off to ‘save power’ and thus preventing access to the computer entirely.
It is easy for those who work on systems to deprecate end-users’ experiences by saying “We know best”. Projects like Fedora should exist solely for the benefit to end-users and anything that injures their use of Fedora should be avoided at all costs.
This specific proposal may be able to find a way to prevent the impacts to Minecraft and other applications. If those impacts can be eliminated, then my opposition to this proposal will go away. As is said in the text of the proposal, we do not want to repeat the jdk6/7 experience.
No specific reason for Zulu over anything else, it’s just an OpenJDK build. (I think it might have been Coretto even, since that’s what IntelliJ seems to download automatically.)
Zulu is certainly not dead, but pretty much the only notable advantage of it over Adoptium for non-legacy-legacy Java versions I’m aware of is that you can hotlink to a specific OS/version/distro type combination on the download site, which is irrelevant here but matters when you need to tell end users to download a java tarball. (They do still offer Java 6 and 7, though) Edit: It appears my info on hotlinking here is outdated or wrong.
JBR and GraalVM have technical advantages over standard OpenJDK builds.
Not as much in the Minecraft community, at least, and I’m not sure I’d call it that specialized.
Of course, I don’t expect the majority of Fedora users to play Minecraft on Fedora, but it’s not like any of us have any data on that. Would be quite nice if we did. But for the subset that does, I would certainly not call modding older versions a highly specific requirement. And a large part of those are likely not to be very experienced with Linux or Fedora, going by my experience with helping people in the community.
So enabling and installing third-party JDKs needs to be as simple as possible, at minimum relative to what it’d be like now. Just linking to Adoptium somewhere in the docs wouldn’t do the trick and would likely shift user support effort onto launchers (and possibly other non-Minecraft-related software), but I’m not sure what the “right” thing to do would be.
A clean upgrade path, especially enabling the repository if the user has legacy JDKs installed, is IMO required. It would be undesirable to leave users with unsupported JDK packages despite updates being available that may even include serious security fixes, and simply uninstalling it entirely is IMO unacceptable.
And of course I think we’d need some guarantees on availability. If Adoptium’s repository starts slacking on supporting Fedora versions again, or disappears entirely… that should result in some sort of action being taken here, with improvements or a possible replacement.
kbb1000, actually , All people around Fedora OpenJDK consider Fedora minecraft community as quite important base! Many OpenJDK bugs were found thanx to minecraft. So… kbb1000, actually for us, who have not seen minecraft for more then decade, is there posibibility to change it to testcase, that Minecraft remain playbale/usbale/modable on Fedora? Any description appreciated!
Hi Tyler, what do you think this change will break? If this change do not exists, Fedora will lost three LTS jdks. It is replacing OpenJDK by OpenJDK. Integration remains as it is.
it is actually preventing security issues, becasue I’m constantly late with security fixes, adoptium temurin is not.
And you are right, we do not want to repeat jdk6/7 which we dropped without replacement, and community was unable to continue. (Still downstream jdk can not live without upstream, so it will be there only as lon as the upstream is here)
It is my impression that some Minecraft users will no longer be able to run that software on Fedora 42 because of somewhat specialized JVM configurations that are currently supported. If you believe there will be absolutely no impact to any existing JVM configuration when a user migrates to Fedora 42, then please correct my understanding.
I commented on this proposed change because we lost the ability to access some systems because of the careless way a power management change was handled. It was made worse by the devs basically stating “tough luck” your configuration is not important enough for use to consider. This proposal seemed to have the same possible impact on a number of existing Fedora users.
I have been a Fedora/Redhat user since Redhat 6. I like Fedora because it mostly tries to avoid damage a user’s use of their hardware and applications. This change, according to the other comments I read, seems like it could break a bunch of use cases. I hope that I am wrong and that you can provide details about why all existing, working configurations will continue to function properly.
I do understand and appreciate some of the benefits of this proposal, but breaking existing uses almost always is worse than any loss of benefits that not implementing a proposal might incur.
The Wiki page contains zero mentions of the word “retire”, which is why I’m asking.
This is not, in general, how Fedora works. The only reason (that I know of) that packages can not be added (back) to Fedora would be legal reasons (i.e. unacceptable license terms or export restrictions around cryptography). I don’t think there is precedent for blocking people from adding back a retired package for the reasons you outline here, and there is no procedure for it.
Agreed. This was pretty extensively litigated during the KDE Plasma 6 Change, and this strikes me as a similar scenario in spirit. I don’t know if someone will volunteer to do the work and maintain these packages, but preemptively blocking them seems wrong.
I would love to, but I can not correct you, because I do not know those scenarios. From my understanding of jvm, there will be minimal changes for any end user. But I can not see to all corners.
I’m glad you commented. And I’m reading that. Af rot the minecraft - I do not now how to test this. The only possibl testing would be by minecraft people to try f42 early enough so I can adapt.
Hello! This is very valid point and one of the heart beats of the proposal.
One part of universe seems to have update path from legacy LTS openjdks to temurins smooths, others may love more to have an option and to maintain them still in fedora (maybe with paralel temurins, or maybe without them at all).
I can orphan the jdks
I can orphan the jdks, and just include the third party repo by default off
I can orphan the jdks, and just include the third party repo by default on
All works for me.
However, jdk 6 and 7 really gave us an expereince that JDK can not stay just-community-package.
So I can imagine a smooth update path as described in proposal:
jdk8 and 11 and 17 will depend on the repo
will coexists with it for a while, alhough stripped of all provides.
later will its java/javac stop working and will be jsut printing “download temurins” or similarly, and will remain hollow.
the most smooth transition would be if they will be jsut metapackage requiring temurin of of same version, but that do not seem correct by guidelines.
I really do not have strong opinion on this, and am open to suggestions, and whatever we agree on, will happen.
I’m still confused (or maybe you are?) about the different processes for orphaning and / or retiring packages in Fedora, and this is not addressing my confusion at all, sorry.
(also please consider enabling the spell checker in your browser, your posts are often quite hard to read due to the frequency of typos.)
The openjdk (8-17) packages can be both orphaned xor retired. I really do not have strong preference. I would like to have a discussion, which I believe we have now, about what is best to do. I will narrow the proposal accordingly. For smooth transition, it is necessary to retire them. Reading this discussion, it seems it is going this way.
It does, thank you. However, you might want to consider that you can only retire the packages in rawhide (and branched, before GA). If you intend to orphan and retire them, would this mean that OpenJDKs in stable branches before Fedora 42 would become unmaintained?
Then “orphaning” is absolutely the wrong thing to do. You can only orphan a package entirely or not at all, but not specific branches only. So if you plan to continue maintaining these OpenJDKs on older branches of Fedora until they are EOL, you cannot orphan them, but only retire them for Fedora 42+.