Latest revision as of 08:50, 25 September 2024

Adjust java/java-devel requires to multi-vendor JDK world and replace legacy JDKs by third party Eclipse Temurin repositories

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

Adjust java/java-devel provides/requires to multivendor world and obsolete all non-system LTS JDKs (java-1.8.0-openjdk, java-11-openjdk, java-17-openjdk in time of writing) by appropriate, properly integrating, RPMs from Eclipse Adoptium repositories.

Owner

Name: Jiri Vanek
Email: <jvanek@redhat.com>
Product: java and java stack
Responsible WG: java-sig (java and java-maint)(which no longer exists)
rcm ticket: https://pagure.io/releng/issue/TODO
named side tag ticket: tbd

Current status

Targeted release: Fedora Linux 42
Last updated: 2024-09-25
Writing in progress
Announced
Discussion thread
FESCo issue: <will be assigned by the Wrangler>
FESCo exception/denial to enable temurin repos by default: todo by maintainer once appropriate
Tracker bug: <will be assigned by the Wrangler>
Release notes tracker: <will be assigned by the Wrangler>

Expected schedule

Eclipse Temurin repositories already exists: https://adoptium.net/installation/linux/#_centosrhelfedora_instructions
RPMs can be easily integrated. Remaining issues are summed up at: https://github.com/adoptium/installer/issues/848 ; but they do not block immediate usage
RPM with repository on review: https://bugzilla.redhat.com/show_bug.cgi?id=2313339
JDKs will be obsoleted from f42 onwards only. The Repository may be available also for older Fedoras, as they can coexists.
to keep en system-jdk idea as it is, the requires of "java", "java-devel" and "java-headless" were revisited
- those will be encapsulated them to "javapackages-tools" and "javapavckages-local" which handles system JDK anyway in user independent way (https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_java_command_setting#Summary)
- the documentation of https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_buildrequires_and_requires will be updated
- all non-system LTS JDKs will be orphaned or replaced by obsoleting package with possible dependency on the repository wrapper)

As 'Change Checkpoint: Proposal submission deadline (System Wide Changes) Tue 2024-12-24' and 'Branch Fedora Linux 42 from Rawhide Tue 2025-02-04' is in reasonable time, we hope to finish all peacefully (as all initial tests are already finished).

Detailed Description

Fedora currently ships:

java-1.8.0-openjdk (LTS)
java-11-openjdk (LTS)
java-17-openjdk (LTS)
java-21-openjdk (LTS), system JDK
java-latest-openjdk (STS) - currently JDK22, soon JDK23, in time of finish JDK24
In future, java-25-openjdk (LTS) will fork from java-latest-openjdk, and will become system jdk, as jdk21 before (https://fedoraproject.org/wiki/Changes/Java21#java-21-openjdk_as_the_system_JDK_in_F40) and jdk17 before that and so on...
- java-21-openjdk will then follow the fate of java-17-openjdk, 11 and 1.8.0 as written lower.

We, OpenJDK maintainers in Fedora, would like to orphan/close/obsolete non system JDKs in favor of Temurin JDKs. Adoptium Temurin (https://adoptium.net/temurin/releases/) is de-facto standard build of JDK, with huge support and compatibility, and all current Fedora JDK contributors are long term members and contributors to Temrun JDK (and its RPMs). Adoptium is dedicated, to keep Temurin RPMs well integrated and healthy for Fedora. Adoptium efforts are tracked in https://github.com/adoptium/installer/issues/848 . Adoptium is maintaining theirs repos (https://adoptium.net/installation/linux/#_centosrhelfedora_instructions) for ages, and they're heavily used.

Practically We see several approaches:

simply orphan jdk 8,11 and 17 (in f42 the only system JDK will be 21)
- However past (orphaning of jdk 6 and 7 ) had learned us a lesson that avarage packager (despite being experienced java/C programmer) is unable to maintain OpenJDK packages
orphan the packages and close them. enhance https://docs.fedoraproject.org/en-US/quick-docs/installing-java/ that non system JDK can be installed after enabling the adoptium repos (https://adoptium.net/installation/linux/#_centosrhelfedora_instructions)
orphan the packages and close them.
- provide rpm which will contain the 3d party repository\
- enhance https://docs.fedoraproject.org/en-US/quick-docs/installing-java/ informing about that

provide rpm which will contain the 3d party repository\
- integrate it with gnome software and and fedora setup of 3rd party repos
- we would like try to do an fluent transition - so the current 8,11 and 17 packages will also install the rpm wiht repository files and thus once we remove jdk8-17 (or future) from distribution, they will be smoothly updated by temurin jdk (with check if other 3rd party repos are enabled)

java-latest-openjdk remain also maintained in Koji, as it is necessary testing ground for future system JDK.

It was never an intention to repack a binary Temurin blob in Koji (just in case anybody will think about it). It is not an intention to get rid of maintaining System JDK. However once JDK will no longer be System jdk in any live Fedora, it will be orphaned/closed in favor of Temurin JDK. So once f42 will go out we will continue to maintain only jdk 23+21. In some short time, we will maintain 25+21, a bit alter 26+25+21... And once 25 will become system JDK in all live fedoras, we will ditch 21 in favor of Temurins

java packages `requires` mass change

The javastack (via javapackages-tools) will be reworked to:

encapsulate dependencies on system jdk (or any other koji-based jdk) to javapackages tools
allow any application to work on any, even 3rd party java

This should be achieved via following chnages to reqires changes and generated changes:

javapackages-local for packages with ant or no build - requires java-%{system}-openjdk-devel (%jpackage_script)
- javapavckages-local%VERSIONED for older ones
- For slower transitions to newer jdks
javapackages-tools
- requires java-%{system}-openjdk-headless
- javapackages-tools%VERSIONED for older ones
- Do not requires java-%{system}-openjdk
  - Will not be added - satisfied by Javapackages-tools with java || java-xyz-openjdk requires
Requires generator which crawls through launchers of packages (including jpackage_script ) which source java_functions
- will be pointing to used jre headless
- %jpackage_script is implicitly affected by generator and will generate requires to corresponding %{build_time_sdk's}-headless jre (which is currently system jdk, which is jdl 21, unless specified differently)
Other packages will need to manually adjust from java-%{system}-openjdk-/headless/devel to java-(system+1)-openjdk-/headless/devel
- This affects mass rebuilds (instead of just release++ a java-xy-openjdk must do xy++). Positive si that there is more time to do that
- Indirectly this is not enforcing new system jdk when new LTS is promoted in Fedora
  - Otherwise generic java-devel will no longer satisfy new systemjdk after system bump

JAVA_HOME remains main override (rpm generated requires are not affected (maybe todo?))

https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/ will be adjusted accordingly

the packages built by pure javac or jsut build requires java without any javapackages tools will be adjsuted manually

Note, that this is much smaller effort then it looks like. 99% of packages are living with generated provides, and will get the change automagically. The remaining - aprox 10 - packages will be handled manually

Feedback

todo

Benefit to Fedora

The number of legacy JDKs have grown, and hand in hand with that the number of theirs usages dropped to minimum. It seems there is no longer any need to maintain them, as theirs usage is only highly specialized. By providing 3rd party repo, we allow the specialized use-cases to continue to exist. By discontinuing theirs build in koji we well untie or hands to move forward and focus on future JDKs. Also we will enable fedora to provide highly stable, often updated, secure, 100% integrate-able and passionately maintained builds of legacy JDKs, which will serve as proper replacement if really needed. As a side effect of the changes in provides/requires, we will allow every JDK, from any vendor, which follows unofficial packaging JEP (which covers java and javac alternatives master and java/java-devel provides) to be effectively part of system if wanted, and not just silent companion.

More time for pacakges to react to new LTS

Another positive is more time for packages to adapt and/or die faster. Currently, if package was unable to adjsut to new system JDK, the package was moved to require exactly one, versioned, known newest java it worked with. And so it very often went rotten. Now, if new LTS is introduced, the package will still work with the previous one, until the owner decides to really move on. If not, then this package will die by its own in *one year*, when "it's" jdk will be removed from fedora

Scope

Proposal owners:
- will provide and maintain the 3rd party repo - https://bugzilla.redhat.com/show_bug.cgi?id=2313339
- will help to integrate it with gnome-software and other 3rd party repos units
- will orphan or replace (based on agreement on details
- will update java packages documentation
- we will fix all the direct requires java/java-devel (aprox 14 only)
- we will communicate with packagers of known, remainingm packages which do not run with system jdk (aprox 5 )

Other developers:
- javapackages-tools, maven and ant maintainers are already on board to to totally decuple system jdk from installed java

Release engineering: #Releng issue number
- I think the mass rebuild will not be needed

Policies and guidelines: N/A (not needed for this Change)
- java packaging guidelines will be updated

Trademark approval: N/A (not needed for this Change)

Alignment with the Fedora Strategy:
- This proposal is aligned with Fedora mission - to be on top of technology. We want to focus on newer JDKs, and still provide comfortable access to legacy ones,

Upgrade/compatibility impact

No meter what approach will be selected at the end, there will be upgrade impact.

in ideal usecase, the JDKs from koji simply replaces themselves by those from Eclipse Temurin
in worst case, user will just get disabled 3rd party repo and updated docs.

In all cases system jdk will remain on machine, and in all cases legacy jdks will be replaced or disappear. I would really be unhappy to simply discontinue them, and leave unmaintained software on target boxes.

Early Testing (Optional)

Do you require 'QA Blueprint' support? Y

How To Test

No JDK on system

get system without java
update to next fedora
no JDK should be there

Only system JDK on system and future STS jdk

get system with system jdk only
update to next fedora
JDK should be there

Only legacy JDK

get system withotu any JDK
manually install any of legacy LTS jdks
update to next fedora
the legacy jdk should not be there or should be gone

System JDK and legacy JDK

get system with system jdk only
manually install any of legacy LTS jdks
update to next fedora
system JDK should be there
the legacy jdk should not be there or should be gone

User Experience

As already described, basic users should not notice change. Advanced users should not lost.

Dependencies

Several (less then 10) packages will lost theirs main dependencies. Those list will be enumerated. Those packages will need to orphan and move to different kind of distribution or update. Main java stack - the packages depending on system java/java-devel/java-headless/java-packages-tools and similar, should not notice change.

Contingency Plan

Contingency mechanism: If we fails to introduce Eclipse Temurin JDKs repo, we will simply orphan legacy JDKs as written earlier
Contingency deadline: 1. December 2024
Blocks release? Yes

Documentation

Only eclipse temurin install pages and java packages guidelines

todo link1
todo link2

...

The content of the changes to guidelines will be mostly based on https://fedoraproject.org/wiki/Changes/ThirdPartyLegacyJdks#java_packages_requires_mass_change

Release Notes

From user point of view, not that much should chage. Based on the result of https://fedoraproject.org/wiki/Changes/ThirdPartyLegacyJdks#Detailed_Description users will be informed:

java 8,11 and 17 are gone
they are maybe replaced by temurins
they temurisn are maybe enabled by default
in all cases temurins can be used
- how
the feature is forward rolling, and once LTS jdk wills top being system jdk, it will drift to temurins too.

Search

Changes/ThirdPartyLegacyJdks: Difference between revisions

Latest revision as of 08:50, 25 September 2024

Contents

Adjust java/java-devel requires to multi-vendor JDK world and replace legacy JDKs by third party Eclipse Temurin repositories

Summary

Owner

Current status

Expected schedule

Detailed Description

java packages `requires` mass change

Feedback

Benefit to Fedora

More time for pacakges to react to new LTS

Scope

Upgrade/compatibility impact

Early Testing (Optional)

How To Test

User Experience

Dependencies

Contingency Plan

Documentation

Release Notes

@@ Line 1: / Line 1: @@
-{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.<br/> '''Copy the source to a ''new page'' before making changes!  DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.'''}}
-{{admon/tip | Guidance | For details on how to fill out this form, see the [https://docs.fedoraproject.org/en-US/program_management/changes_guide/ documentation].}}
+= Adjust java/java-devel requires to multi-vendor JDK world and replace legacy JDKs by third party Eclipse Temurin repositories =
-{{admon/tip | Report issues | To report an issue with this template, file an issue in the [https://pagure.io/fedora-pgm/pgm_docs pgm_docs repo].}}
-<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
-= Change Proposal Name <!-- The name of your change proposal --> =
 {{Change_Proposal_Banner}}
@@ Line 13: / Line 6: @@
 == Summary ==
 <!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. Note that motivation for the change should be in the Benefit to Fedora section below, and this part should answer the question "What?" rather than "Why?". -->
+Adjust java/java-devel `provides/requires` to multivendor world and obsolete all non-system LTS JDKs (java-1.8.0-openjdk, java-11-openjdk, java-17-openjdk in time of writing) by appropriate, properly integrating, RPMs from Eclipse Adoptium repositories.
 == Owner ==
-<!--
+* Name: [[User:jvanek| Jiri Vanek]]
-For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages.
+* Email: <jvanek@redhat.com>
-This should link to your home wiki page so we know who you are.
+* Product: java and java stack
--->
+* Responsible WG: java-sig (java and java-maint)(which no longer exists)
-* Name: [[User:FASAcountName| Your Name]]
+* rcm ticket: https://pagure.io/releng/issue/TODO
-<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
+* named side tag ticket: tbd
-* Email: <your email address so we can contact you, invite you to meetings, etc. Please provide your Bugzilla email address if it is different from your email in FAS>
-<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
-* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
--->
 == Current status ==
-[[Category:ChangePageIncomplete]]
+ [[Category:ChangeAnnounced]]
 <!-- When your change proposal page is completed and ready for review and announcement -->
 <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
 <!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) -->
 <!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete-->
 <!-- Select proper category, default is Self Contained Change -->
-[[Category:SelfContainedChange]]
+<!-- [[Category:SelfContainedChange]] -->
-<!-- [[Category:SystemWideChange]] -->
+[[Category:SystemWideChange]]
-* Targeted release: [https://docs.fedoraproject.org/en-US/releases/f<VERSION>/ Fedora Linux <VERSION>]
+* Targeted release: [https://docs.fedoraproject.org/en-US/releases/f42/ Fedora Linux 42]
 * Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
 <!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page
@@ Line 46: / Line 35: @@
 ON_QA -> change is fully code complete
 -->
-* [Announced]
+* Writing in progress
-* [<will be assigned by the Wrangler> Discussion thread]
+* [https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/thread/AKNHHXKEEKGHIAALVDOHX3IWIS3Y77LG/ Announced]
+* [https://discussion.fedoraproject.org/t/f42-change-proposal-third-party-legacy-jdks-system-wide/132049 Discussion thread]
 * FESCo issue: <will be assigned by the Wrangler>
+* FESCo exception/denial to enable temurin repos by default: todo by maintainer once appropriate
 * Tracker bug: <will be assigned by the Wrangler>
 * Release notes tracker: <will be assigned by the Wrangler>
+<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
+=== Expected schedule ===
+* Eclipse Temurin repositories already exists: 	https://adoptium.net/installation/linux/#_centosrhelfedora_instructions
+* RPMs can be easily integrated. Remaining issues are summed up at: https://github.com/adoptium/installer/issues/848 ;  but they do not block immediate usage
+* RPM with repository on review: https://bugzilla.redhat.com/show_bug.cgi?id=2313339
+* JDKs will be obsoleted  from f42 onwards only. The Repository may be available also for older Fedoras, as they can coexists.
+* to keep en system-jdk idea as it is, the requires of "java", "java-devel" and "java-headless" were revisited
+** those will be encapsulated them to "javapackages-tools" and "javapavckages-local" which handles system JDK anyway in user independent way (https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_java_command_setting#Summary)
+** the documentation of https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_buildrequires_and_requires will be updated
+**  all non-system LTS JDKs will be orphaned or replaced by obsoleting package with possible dependency on the repository wrapper)
+As 'Change Checkpoint: Proposal submission deadline (System Wide Changes) Tue 2024-12-24' and 'Branch Fedora Linux 42 from Rawhide Tue 2025-02-04' is in reasonable time, we hope to finish all peacefully (as all initial tests are already finished).
 == Detailed Description ==
-<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
+<!--
+{{admon/important | JDK TEAM NOTE: | in el10 there is only one jdk, however, the non binding java/java-devel, and all the whole "system jdk in javapackages-tools" is quite a precedent for it, and considering we will be updating system jdk in el aprox 3x, we should take exceptional care here, as it may solve - or bite back - the issue we are facin gin el9 now}}
+-->
+Fedora currently ships:
+* java-1.8.0-openjdk (LTS)
+* java-11-openjdk (LTS)
+* java-17-openjdk (LTS)
+* java-21-openjdk (LTS), system JDK
+* java-latest-openjdk (STS) - currently JDK22, soon JDK23, in time of finish JDK24
+* In future, java-25-openjdk (LTS) will fork from java-latest-openjdk, and will become system jdk, as jdk21 before (https://fedoraproject.org/wiki/Changes/Java21#java-21-openjdk_as_the_system_JDK_in_F40) and jdk17 before that and so on...
+** java-21-openjdk will then follow the fate of java-17-openjdk, 11 and 1.8.0 as written lower.
+We, OpenJDK maintainers in Fedora, would like to orphan/close/obsolete non system JDKs in favor of Temurin JDKs. Adoptium Temurin (https://adoptium.net/temurin/releases/) is de-facto standard build of JDK, with huge support and compatibility, and all current Fedora JDK contributors are long term members and contributors to Temrun JDK (and its RPMs).
+Adoptium is dedicated, to keep Temurin RPMs well integrated and healthy for Fedora. Adoptium efforts are tracked in https://github.com/adoptium/installer/issues/848 . Adoptium is maintaining theirs repos
+(https://adoptium.net/installation/linux/#_centosrhelfedora_instructions) for ages, and they're heavily used.
+Practically We see several approaches:
+* simply orphan jdk 8,11 and 17 (in f42 the only system JDK will be 21)
+** However past (orphaning of jdk 6 and 7 ) had learned us a lesson that avarage packager (despite being experienced java/C programmer) is unable to maintain OpenJDK packages
+* orphan the packages and close them. enhance https://docs.fedoraproject.org/en-US/quick-docs/installing-java/ that non system JDK can be installed after enabling the adoptium repos (https://adoptium.net/installation/linux/#_centosrhelfedora_instructions)
+* orphan the packages and close them.
+** provide rpm which will contain the 3d party repository\
+** enhance https://docs.fedoraproject.org/en-US/quick-docs/installing-java/ informing about that
+* provide rpm which will contain the 3d party repository\
+** integrate it with gnome software and and fedora setup of 3rd party repos
+** we would like try to do an fluent transition - so the current 8,11 and 17 packages will also install the rpm wiht repository files and thus once we remove jdk8-17 (or future) from distribution, they will be smoothly updated by temurin jdk (with check if other 3rd party repos are enabled)
+java-latest-openjdk remain also maintained in Koji, as it is necessary testing ground for future system JDK.
+It was never an intention to repack a binary Temurin blob in Koji (just in case anybody will think about it).
+It is not an intention to get rid of maintaining System JDK. However once JDK will no longer be System jdk in any live Fedora, it will be orphaned/closed in favor of Temurin JDK. So once f42 will go out we will continue to maintain only
+jdk 23+21. In some short time, we will maintain 25+21, a bit alter 26+25+21... And once 25 will become system JDK in all live fedoras, we will ditch 21 in favor of Temurins
+=== java packages `requires` mass change ===
+The javastack (via javapackages-tools) will be reworked to:
+*encapsulate dependencies on system jdk (or any other koji-based jdk) to javapackages tools
+*allow any application to work on any, even 3rd party java
+This should be achieved via following chnages to reqires changes and generated changes:
+*`javapackages-local` for packages with `ant` or no build - `requires java-%{system}-openjdk-devel` (`%jpackage_script`)
+**`javapavckages-local%VERSIONED` for older ones
+**For slower transitions to newer jdks
+*`javapackages-tools`
+**`requires java-%{system}-openjdk-headless`
+**`javapackages-tools%VERSIONED` for older ones
+**Do not requires java-%{system}-openjdk
+***'''Will not be added''' - satisfied by Javapackages-tools with java || java-xyz-openjdk requires
+* Requires generator which crawls through launchers of packages (including `jpackage_script` ) which source `java_functions`
+** will be pointing to used jre headless
+**`%jpackage_script` is implicitly affected by generator and will generate requires to corresponding `%{build_time_sdk's}-headless jre`  (which is currently system jdk, which is jdl 21, unless specified differently)
+*Other packages will need to manually adjust from `java-%{system}-openjdk-/headless/devel` to `java-(system+1)-openjdk-/headless/devel`
+**This affects mass rebuilds (instead of just release++ a java-xy-openjdk must do xy++). Positive si that there is more time to do that
+** Indirectly this is '''not enforcing''' new system jdk when new LTS is promoted in Fedora
+***Otherwise generic `java-devel` will no longer satisfy new systemjdk after system bump
+*`JAVA_HOME` remains main override (rpm generated requires are not affected (maybe todo?))
+https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/ will be adjusted accordingly
+the packages built by pure javac or jsut build requires java without any javapackages tools will be adjsuted manually
+'''Note, that this is much smaller effort then it looks like. 99% of packages are living with generated provides, and will get the change automagically. The remaining - aprox 10 - packages will be handled manually'''
 == Feedback ==
 <!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. -->
+todo
 == Benefit to Fedora ==
@@ Line 86: / Line 154: @@
       https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
 -->
+The number of legacy JDKs have grown, and hand in hand with that the number of theirs usages dropped to minimum. It seems there is no longer any need to maintain them, as theirs usage is only highly specialized.
+By providing 3rd party repo, we allow the specialized use-cases to continue to exist. By discontinuing theirs build in koji we well untie or hands to move forward and focus on future JDKs. Also we will enable fedora to provide highly stable, often updated, secure, 100% integrate-able and passionately maintained builds of legacy JDKs, which will serve as proper replacement if really needed. As a side effect of the changes in `provides/requires`, we will allow every JDK, from any vendor, which follows unofficial packaging JEP (which covers java and javac alternatives master and java/java-devel provides) to be effectively part of system if wanted, and not just silent companion.
+=== More time for pacakges to react to new LTS ===
+Another positive is more time for packages to adapt and/or die faster. Currently, if package was unable to adjsut to new system JDK, the package was moved to require exactly one, versioned, known newest java it worked with. And so it very often went rotten. Now, if new LTS is introduced, the package will still work with the previous one, until the owner decides to really move on. If not, then this package will die by its own in *one year*, when "it's" jdk will be removed from fedora
 == Scope ==
 * Proposal owners:
 <!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
+** will provide and maintain the 3rd party repo - https://bugzilla.redhat.com/show_bug.cgi?id=2313339
+** will help to integrate it with gnome-software and other 3rd party repos units
+** will orphan or replace (based on agreement on `details`
+** will update java packages documentation
+** we will fix all the direct requires java/java-devel (aprox 14 only)
+** we will communicate with packagers of known, remainingm  packages which do not run with system jdk (aprox 5 )
 * Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 <!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
+** javapackages-tools, maven and ant maintainers are already on board to to totally decuple system jdk from installed java
 * Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.
 The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
+** I think the mass rebuild will not be needed
 * Policies and guidelines: N/A (not needed for this Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 <!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. Please submit a pull request with the proposed changes before submitting your Change proposal. -->
+** java packaging guidelines will be updated
 * Trademark approval: N/A (not needed for this Change)
@@ Line 106: / Line 187: @@
 * Alignment with the Fedora Strategy:
 <!-- Does your proposal align with the current Fedora Strategy: https://discussion.fedoraproject.org/t/fedora-strategy-2028-february-march-planning-work-and-roadmap-til-flock/43618 ? It's okay if it doesn't, but it's something to consider -->
+** This proposal is aligned with Fedora mission - to be on top of technology. We want to focus on newer JDKs, and still provide comfortable access to legacy ones,
 == Upgrade/compatibility impact ==
 <!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
+No meter what approach will be selected at the end, there will be upgrade impact.
+* in ideal usecase, the JDKs from koji simply replaces themselves by those from Eclipse Temurin
+* in worst case, user will just get disabled 3rd party repo and updated docs.
+In all cases system jdk will remain on machine, and in all cases legacy jdks will be replaced or disappear. I would really be unhappy to simply discontinue them, and leave unmaintained software on target boxes.
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
@@ Line 115: / Line 202: @@
 <!-- This is an optional step for system-wide changes to avail of. If you would like to build an initial proof of concept of your change and have a member of Fedora QA help you write and/or run some initial basic tests on your code, please email tests@fedoraproject.org and include the link to your change proposal. This step is *optional*. -->
-Do you require 'QA Blueprint' support? Y/N <!-- Optional Step for System-Wide Changes only -->
+Do you require 'QA Blueprint' support? Y <!-- Optional Step for System-Wide Changes only -->
 == How To Test ==
@@ Line 131: / Line 218: @@
 . What are the expected results of those actions?
 -->
+No JDK on system
+# get system without java
+# update to next fedora
+# no JDK should be there
+Only system JDK on system and future STS jdk
+# get system with system jdk only
+# update to next fedora
+# JDK should be there
+Only legacy JDK
+#  get system withotu any JDK
+#  manually install any of legacy LTS jdks
+#  update to next fedora
+#  the legacy jdk should not be there or should be gone
+System JDK and legacy JDK
+#  get system with system jdk only
+#  manually install any of legacy LTS jdks
+#  update to next fedora
+#  system JDK should be there
+#  the legacy jdk should not be there or should be gone
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
@@ Line 145: / Line 254: @@
   - Green has been scientifically proven to be the most relaxing color. The move to a default background color of green with green text will result in Fedora users being the most relaxed users of any operating system.
 -->
+As already described, basic users should not notice change. Advanced users should not lost.
 == Dependencies ==
 <!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel change)? -->
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+Several (less then 10) packages will lost theirs main dependencies. Those list will be enumerated.
+Those packages will need to orphan and move to different kind of distribution or update.
+Main java stack - the packages depending on system java/java-devel/java-headless/java-packages-tools and similar, should not notice change.
 == Contingency Plan ==
 <!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
-* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Contingency mechanism: If we fails to introduce Eclipse Temurin JDKs repo, we will simply orphan legacy JDKs as written earlier
 <!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
-* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Contingency deadline:  1. December 2024
 <!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
-* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Blocks release? Yes <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 == Documentation ==
 <!-- Is there upstream documentation on this change, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
+Only eclipse temurin install pages and java packages guidelines
+* todo link1
+* todo link2
+...
-<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+The content of the changes to guidelines will be mostly based on https://fedoraproject.org/wiki/Changes/ThirdPartyLegacyJdks#java_packages_requires_mass_change
-N/A (not a System Wide Change)
 == Release Notes ==
@@ Line 174: / Line 289: @@
 Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.
 -->
+From user point of view, not that much should chage. Based on the result of https://fedoraproject.org/wiki/Changes/ThirdPartyLegacyJdks#Detailed_Description users will be informed:
+* java 8,11 and 17 are gone
+* they are maybe replaced by temurins
+* they temurisn are maybe enabled by default
+* in all cases temurins can be used
+** how
+* the feature is forward rolling, and once LTS jdk wills top being system jdk, it will drift to temurins too.

Search

Changes/ThirdPartyLegacyJdks: Difference between revisions

Latest revision as of 08:50, 25 September 2024

Adjust java/java-devel requires to multi-vendor JDK world and replace legacy JDKs by third party Eclipse Temurin repositories

Summary

Owner

Current status

Expected schedule

Detailed Description

java packages requires mass change

Feedback

Benefit to Fedora

More time for pacakges to react to new LTS

Scope

Upgrade/compatibility impact

Early Testing (Optional)

How To Test

User Experience

Dependencies

Contingency Plan

Documentation

Release Notes

java packages `requires` mass change