< Changes
Build JDKs once, repack everywhere
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 tarballs into RPMs. Currently, the portable 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 or 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-31
- devel thread
- 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 dramatically. As described in the same wiki page and in individual sub changes and devel threads, the primary reason for this is to lower maintenance and still keep Fedora Java friendly.
- In the first system wide change, we have changed the JDKs to build properly as standalone, portable JDK - the way JDK is supposed to be built. I repeat, we spent ten years by patching JDK to become properly dynamic against system libs, and all patches went upstream, but this has become a fight which can not be won.
- As a second step we introduced portable RPMs, which do not have any system integration, only build JDK and pack the final tarball in RPM for Fedora 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 just 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 after 22... Should be built in oldest live EPEL - epel8 now. We have verified, that such repacked JDKs works fine.
theoretical tagging solution
1. request side tags for all releases
2. build the actual Java in the side tag for the oldest thing
3. tag the result ot (2) to all side tags from (1)
4. waitrepo them
5. build the repacked java packages in all the side tags from (1)
6. untag the result of (2) from all the side tags from (1)
7. ship bodhi updates from side tags OR retag the builds to candidate tags
(and delete the side tags)
The build from (2) will be eventually garbage collected. To prevent that, it might be re-tagged regularly. This is where releng might be able to help by creating a long lived tag to tag this into for preserving.
Yes, we could make a 'fN-openjdk' tag and mark it protected... that part would be easy enough.
Feedback
Benefit to Fedora
Java maintainers will finally have 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 JDK.
If we fail to build once and repack everywhere, Java maintainers will most likely need to lower the number of JDKs in fedora to system one only.
Scope
- Proposal owners: Technically all JDKs (except 8, where some more tuning is needed, and EPEL for java-latest) are prepared, as they have a portable version, and RPMs just repack it. Except tuning up the JDK8 and EPEL for latest, scope owners 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 lose their 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.
SRPM rebuild of both portables (which were built once) and of any rpms (from this freshly rebuild portbales) have to remain possible
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 chain 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)