< Changes
No edit summary |
(Fix formatting) |
||
| Line 40: | Line 40: | ||
* Product: java and java stack | * Product: java and java stack | ||
* Responsible WG: java-sig (java and java-maint)(which no longer exists) | * Responsible WG: java-sig (java and java-maint)(which no longer exists) | ||
== Current status == | == Current status == | ||
| Line 57: | Line 57: | ||
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | ||
--> | --> | ||
* FESCo issue: | * FESCo issue: [https://pagure.io/fesco/issue/2770 #2770] | ||
* Tracker bug: | * Tracker bug: <will be assigned by Wrangler> | ||
* Release notes | * Release notes <will be assigned by Wrangler> | ||
=== Expected schedule === | === Expected schedule === | ||
| Line 121: | Line 121: | ||
<!-- 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?--> | <!-- 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?--> | ||
* Release engineering: | * Release engineering: [https://pagure.io/releng/issue/10686 #10686] | ||
** mass rebuild will NOT be required for this change | ** mass rebuild will NOT be required for this change | ||
<!-- 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. | <!-- 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. | ||
| Line 173: | Line 173: | ||
<!-- 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. --> | <!-- 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: return i686 packages <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Contingency mechanism: return i686 packages <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
* Contingency date: (not provided) | |||
== Documentation == | == Documentation == | ||
Revision as of 15:02, 7 March 2022
Drop i686 builds of jdk8,11,17 and latest (18) rpms from f37 onwards
Summary
java-1.8.0-openjdk, java-11-openjdk, java-17-openjdk and java-latest-openjdk packages will no longer build i686 subpackages
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)
Current status
- Targeted release: Fedora 37
- Last updated: 2022-03-07
- FESCo issue: #2770
- Tracker bug: <will be assigned by Wrangler>
- Release notes <will be assigned by Wrangler>
Expected schedule
- during march, drop i686 builds from all jdks in fedora rawhide
Detailed Description
Fedora currently ships:
- java-1.8.0-openjdk (LTS)
- java-11-openjdk (LTS)
- java-17-openjdk (LTS)
- java-latest-openjdk (STS, jdk18).
All those builds on all architectures except jdk8, where arm32 with jit is built by different package. Unluckily, the i686 bit builds of jdk are rotten in upstream. The recent breakage of i686 JIT just before branching nearly killed jdk17 as system jdk feature. The rotting have main visibility with newer GCCs. If GCC bump, and it does, it always triggers new issues in i686 JIT, and there is less and less people to somehow workaround them. Unluckily, there is probably no longer anyone willing to really fix them
Benefit to Fedora
The i686 builds are rotten in usptream, and to patch them localy had become pain. We may be introducing very bugy i686 jdk. Better then to do so, we would rather not ship that at all. This will untie hands of both JDK and GCC developers, who will no longer need to dive into nasty legacy code.
Scope
Change owners
- we will simiply stop building i686 pkg in rawhide
Other developers
- may notice the multilib i686 java missing.
- it is up to them to drop i686 builds or to povide workaround (if possible)
Other
- Release engineering: #10686
- mass rebuild will NOT be required for this change
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
- The upgrade on multilib systems will lead to autoremoval of i686 javastack
- which should be minimum - 99% of javastack is noarch
How To Test
install i686 java will result to not packages found
User Experience
User experience on multilib systems will be bad. Bad reasonable.
Dependencies
There are is unknown number of multilib java consumers. I expect some of them may rise voice, but that will have to handled one by one.
Contingency Plan
- Contingency mechanism: return i686 packages
- Contingency date: (not provided)
Documentation
Will be neded...
Release Notes
None yet...