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