From Fedora Project Wiki
< Changes
(moved back to ChangePageIncomplete) |
No edit summary |
||
| Line 110: | Line 110: | ||
== Scope == | == Scope == | ||
==== Change owners ==== | ==== Change owners ==== | ||
* we will | * After recursive dependency scan was done, i was discovered that the change affects moreover whole system | ||
** initial recursive scan pkg requiring or build requiring java and friends (https://github.com/judovana/FedoraSystemJdkBump/blob/1f126a2d7a4235593b1575467f420b185e5ecb13/scritps/listPkgs/recursiveGlue.sh#L54) pulled in automake and few others, which n second recursive round pulled in moreover whole system | |||
*** I do no have record of this search as it was useless | |||
** Second run was run without automake. Still second round took in automake and thus third and fourth recursion run into morevoer whole system. | |||
*** those results are already parse able. I even generated the chart, but that was pretty flat pointng to automake and autoconf | |||
*** Reuslts: https://jvanek.fedorapeople.org/i686Deps/withAutconf.tar.gz | |||
** third run was run again with autoconf and automake, however all '''build time requires''' for '''noarch''' results were omitted, as those have no real impact in real usage | |||
*** unluckily during recursion, automake and autoconf were hit again on level 3 and four, so later whole system got pulled in | |||
*** results: https://jvanek.fedorapeople.org/i686Deps/withNoarcBrOff.tar.gz | |||
** final sane scan was done with all '''build time requires''' for '''noarch''' packages ommited, together with big blacklist of already known trouble makers: https://github.com/judovana/FedoraSystemJdkBump/blob/1f126a2d7a4235593b1575467f420b185e5ecb13/scritps/listPkgs/recursiveGlue.sh#L142 | |||
** results https://jvanek.fedorapeople.org/i686Deps/withNoarcBrOffWithBlacklist.tar.gz | |||
** those results are already sane (70 000 edges in unreadable chart) | |||
==== Workflow ==== | |||
* if all goes ok, we will simply stop building i686 java pacakges in rawhide | |||
==== Other developers ==== | ==== Other developers ==== | ||
| Line 132: | Line 147: | ||
* Trademark approval: N/A (not needed for this Change) | * Trademark approval: N/A (not needed for this Change) | ||
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://fedorahosted.org/council/ ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. --> | <!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://fedorahosted.org/council/ ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. --> | ||
* Bug assignees will need to verify the impact of i686 | |||
== Upgrade/compatibility impact == | == Upgrade/compatibility impact == | ||
* The upgrade on multilib systems will lead to autoremoval of i686 javastack | * The upgrade on multilib systems will lead to autoremoval of i686 javastack | ||
* which should be minimum | * which should be minimum if above bugzillas are properly handled | ||
<!-- 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? --> | <!-- 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? --> | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
| Line 174: | Line 190: | ||
== Contingency Plan == | == 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. --> | <!-- 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 java packages <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
* Contingency date: (not provided) | * Contingency date: (not provided) | ||
== Documentation == | == Documentation == | ||
Will be | Will be needed... | ||
== Release Notes == | == Release Notes == | ||
| Line 187: | Line 203: | ||
--> | --> | ||
None yet... | None yet... | ||
Revision as of 13:26, 12 April 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-04-12
- devel thread
- FESCo issue: #2772
- 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
Although there is https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval , this proposal have nothign to do with it, not even inspiration. People about OpenJDK learned about after this jdk one was announced.
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
- After recursive dependency scan was done, i was discovered that the change affects moreover whole system
- initial recursive scan pkg requiring or build requiring java and friends (https://github.com/judovana/FedoraSystemJdkBump/blob/1f126a2d7a4235593b1575467f420b185e5ecb13/scritps/listPkgs/recursiveGlue.sh#L54) pulled in automake and few others, which n second recursive round pulled in moreover whole system
- I do no have record of this search as it was useless
- Second run was run without automake. Still second round took in automake and thus third and fourth recursion run into morevoer whole system.
- those results are already parse able. I even generated the chart, but that was pretty flat pointng to automake and autoconf
- Reuslts: https://jvanek.fedorapeople.org/i686Deps/withAutconf.tar.gz
- third run was run again with autoconf and automake, however all build time requires for noarch results were omitted, as those have no real impact in real usage
- unluckily during recursion, automake and autoconf were hit again on level 3 and four, so later whole system got pulled in
- results: https://jvanek.fedorapeople.org/i686Deps/withNoarcBrOff.tar.gz
- final sane scan was done with all build time requires for noarch packages ommited, together with big blacklist of already known trouble makers: https://github.com/judovana/FedoraSystemJdkBump/blob/1f126a2d7a4235593b1575467f420b185e5ecb13/scritps/listPkgs/recursiveGlue.sh#L142
- results https://jvanek.fedorapeople.org/i686Deps/withNoarcBrOffWithBlacklist.tar.gz
- those results are already sane (70 000 edges in unreadable chart)
- initial recursive scan pkg requiring or build requiring java and friends (https://github.com/judovana/FedoraSystemJdkBump/blob/1f126a2d7a4235593b1575467f420b185e5ecb13/scritps/listPkgs/recursiveGlue.sh#L54) pulled in automake and few others, which n second recursive round pulled in moreover whole system
Workflow
- if all goes ok, we will simply stop building i686 java pacakges 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)
- Bug assignees will need to verify the impact of i686
Upgrade/compatibility impact
- The upgrade on multilib systems will lead to autoremoval of i686 javastack
- which should be minimum if above bugzillas are properly handled
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 java packages
- Contingency date: (not provided)
Documentation
Will be needed...
Release Notes
None yet...