Wiki Link: https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere
On Tue, May 30, 2023 at 7:37 PM Aoife Moloney amoloney@redhat.com wrote:
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: [[User:jvanek| Jiri Vanek]]
- Email: jvanek@redhat.com
== Detailed Description ==
As described in https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ; during last year, packaging of JDKs had changed dramatically. 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 friendly.
- In first system wide change, we had changed JDKs to build properly
as standalone, portable jdk - the wey 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 usptream, but it become fight which can not be 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 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 latest 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 repacked JDKs work 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.
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. 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: [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.
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.
== 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 package, they all bites. From SW point of view, the dependence chain is `normal RPMs build requires portable RPMs` and that's 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)
== Release Notes ==
-- Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford