Changes/BuildJdkOncePackEverywhere

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.

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.

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.

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