From Fedora Project Wiki
m (Jvanek moved page Changes/Drop32bJDKs to Changes/Drop i686 JDKs: 32b was misleading. i686 is better)
No edit summary
Line 71: Line 71:


All those builds on all architectures except jdk8, where arm32 with jit is built by different package.
All those builds on all architectures except jdk8, where arm32 with jit is built by different package.
Unluckily, the  32 bit builds of jdk are rotten in upstream. The recent breakage of i686 jit just before branching nearly killed jdk17 as system jdk feature.
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 GCC. If gcc bump, and it does, it always tirggers new issues in i686 jit, and there is less and less people to fix somehow workaround them. Unluckily, there is probably no longer anyone willing to really fix them
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 ==
== Benefit to Fedora ==
Line 121: Line 121:


* Release engineering: todo <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Release engineering: todo <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
** mass rebuild will 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.  
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 -->
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 -->
Line 164: Line 164:
  - 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.
  - 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.
-->
-->
User experience on multilib systems will be bad.
User experience on multilib systems will be bad. Bad reasonable.
 
== Dependencies ==
== Dependencies ==
There are unknown multilib java consumers. This will need to evolve dynamically
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.


<!-- 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)? -->
<!-- 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)? -->

Revision as of 12:53, 7 March 2022


Drop 32b builds of jdk8,11,17 and latest (18) rpms

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)
  • rcm ticket: todo

Current status

  • Targeted release: Fedora 37
  • Last updated: 2022-03-07
  • FESCo issue: todo
  • Tracker bug: todo
  • Release notes todo

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: todo
    • 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

Documentation

Will be neded...

Release Notes

None yet...

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/Drop_i686_JDKs&oldid=637494"