From Fedora Project Wiki
< Changes
(→Scope) |
(→Scope) |
||
| Line 95: | Line 95: | ||
== Scope == | == Scope == | ||
* Proposal owners: Technically all jdks (except 8, where some more tuning is needed, and epels for java-latest) are prepared, as they have portable version, and rpms just reapck it. Exept tuning up the jdk8 and epel for latest, scope oweners are done. | * Proposal owners: Technically all jdks (except 8, where some more tuning is needed, and epels for java-latest) are prepared, as they have portable version, and rpms just reapck it. Exept tuning up the jdk8 and epel for latest, scope oweners are done. | ||
<!-- '''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?--> | <!-- '''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?--> | ||
* Other developers: There will be needed significant support from RCM and maybe senior fedora | * Other developers: There will be needed significant support from RCM and maybe senior fedora leadership to help to finish the build in oldest and enable to repack everywhere<!-- 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?--> | <!-- 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: [https://pagure.io/releng/ | * '''Release engineering: [https://pagure.io/releng/issue/11438 #11438]''' There will be needed significant support from RCM, where I'm actually unsure what they will have to do to enable this. The mas rebuild will not be needed.<!-- 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. | <!-- 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 111: | Line 110: | ||
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://pagure.io/Fedora-Council/tickets/issues ) 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://pagure.io/Fedora-Council/tickets/issues ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. --> | ||
* Alignment with Community Initiatives: All supported JDKS will remain in Fedora in | * Alignment with Community Initiatives: All supported JDKS will remain in Fedora in highest possible quality with full QA and certification, and its packagers will not lost minds. note, that QA will still run on all live fedoras, not only on the builder one. | ||
<!-- Does your proposal align with the current Fedora Community Initiatives: https://docs.fedoraproject.org/en-US/project/initiatives/ ? It's okay if it doesn't, but it's something to consider --> | <!-- Does your proposal align with the current Fedora Community Initiatives: https://docs.fedoraproject.org/en-US/project/initiatives/ ? It's okay if it doesn't, but it's something to consider --> | ||
Revision as of 10:12, 25 May 2023
Build JDKs once, repack everywhere
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.
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
This is the last step in https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs effort. Jdks in fedora are already static, and we repack portable tarball into rpms. Currently, the portbale tarball is built for each Fedora and Epel version. Goal here is to build each jdk (8,11,17,21,latest (20)) only once, in oldest live Fedora xor Epel and repack in all live fedoras.
Owner
- Name: Jiri Vanek
- Email: jvanek@redhat.com
Current status
- Targeted release: Fedora Linux 39
- Last updated: 2023-05-25
- [devel thread <will be assigned by the Wrangler>]
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
As described in https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ; during last year, packaging of JDKs had changed drammatically. As described in same wiki page, and individual sub changes and devel threads, with primary reason this - to lower maintenance and still keep fedora java frieandly.
- In first system wide change, we had changed JDKs to build properly as standalon, portable jdk - the wey JDK is supposed to be built. I repate, we spent ten years by patching JDK to become properly dynamic against system libs, and all patches went usptream, but it become fight which can notbe win
- as a second step we introduced portable rpms, which do not have any system integration, only builds JDK and pack final tarball in RPM for free use.
- In third step - without any noise, just verified with fesco - https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully integrated rpms. Instead of this, normal RPMS BUildRequire portable rpms and jsut unpack it, and repack it.
Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in oldest live Fedora, and repack everywhere. java-latest-openjdk, which contains latests STS jdk - currently 20, soon briefly 21 and a bit alter 22... Should be built in latest live EPEL - epel8 now. We have verified, that such reapcked JDKs works fine.
Feedback
Benefit to Fedora
java maintainers will finally some free time... No kidding - maintenance and *certification* of so much supported JDKs on so much Fedora versions is brutal. By building once, and repack, we will regain cycles to continue support Fedora with all LTS and one STS javas
Scope
- Proposal owners: Technically all jdks (except 8, where some more tuning is needed, and epels for java-latest) are prepared, as they have portable version, and rpms just reapck it. Exept tuning up the jdk8 and epel for latest, scope oweners are done.
- Other developers: There will be needed significant support from RCM and maybe senior fedora leadership to help to finish the build in oldest and enable to repack everywhere
- Release engineering: #11438 There will be needed significant support from RCM, where I'm actually unsure what they will have to do to enable this. The mas rebuild will not be needed.
- Policies and guidelines: AFAIK none (not needed for this Change)
- Trademark approval: N/A (not needed for this Change)
- Alignment with Community Initiatives: All supported JDKS will remain in Fedora in highest possible quality with full QA and certification, and its packagers will not lost minds. note, that QA will still run on all live fedoras, not only on the builder one.
Upgrade/compatibility impact
The change should be completely transparent to any user.
How To Test
sudo dnf update/install "java*" will install expected set of working packages.
User Experience
The change should be absolutely transparent to any user.
Dependencies
To finish this we will need heavy support from RCM, and maybe others. Although there are precedents with such pacakge, they all bites. From SW point of view, the dependece chnin is normal RPMs build requires portable RPMs and thats all.
Contingency Plan
- Contingency mechanism: It should be stright forward to revert back to building per OS
- Contingency deadline: N/A
- Blocks release? No. The change can be introduced even on the fly to live distributions.
Documentation
N/A (not a System Wide Change)