MoveFedoraJDKsToBecomePortableJDKs

Motivation

To introduce properly working dynamically linked JDK to Fedora took several excellent engineers several years. Even after a decade, there are remaining unfixed issues. And new issues are appearing. All that is simply saying - JDK is designed to be portable, it is not possible to provide dynamic jdk behaving like usual dynamic jdk. Stop introducing features which are from "normal" portable JDK point of view bugs.

To be able to call some build of JDK, an binary have to pass severe certification. We are trying to keep all live JDKs in all fedoras - jdk8,jdk11, jdk17 and latest STS - jdk18 now (19 in half a year). We would like to keep this. But one have to test each build, and with four JDKs in 2-3 live Fedoras, it to much even for small team. After this change is in air, we will certificate each binary only once, and redistribute.

Non goals

It is important to highlight that it is not a goal to change how current rpms works. All current rpms should remain in place. Only the way how the binary got to build, and how it got into rpms will change.

It is also not a goal, to pack third party blob. Jdk will still continue to build in koji as it should.

Main Steps

1. Move JDKs in RPMs to become portable details
2. Introduce new portable rpms, which will provide just packed standalone tarball details
3. Make the normal rpms to not built jdk, but to repack the portable rpms with all integration details

Dates

• first steps should be taken in f37
• the repack-able base pkg wil be introduced asynchronously
• whole repack should be finished in f38
• the changes will affect also older fedoras

Side effects

• affected packages: java-1.8.0-openjdk, java-11-openjdk, java-17-openjdk and java-latest-openjdk (with all subpkgs)

Dynamical JDK links all libraries from OS. Proper portable-like linked jdk is using in-tree (custom built) libraries (eg lcms2, jpeg, png, zip), eg image or font rendering might by slightly different. Bundled libraries will be properly treated:

• https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/
• https://fedoraproject.org/wiki/Bundled_Libraries
• https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling

Details

Move JDKs in RPMs to become portable

For f37 a new system wide change (which will actually backport to older fedoras once verified as completely ok. The patch which have to go to each JDK (8,11,17, latest) is as simple as:

https://src.fedoraproject.org/rpms/java-latest-openjdk/pull-request/98#request_diff

This patch will move to use intree libraries where possible and move stdc++ to static linking We have already tested such jdk deeply, and we know it is working fine in Fedora. Still unknown surprise may occure.

Introduce new portable rpms, which will provide just packed standalone tarball

This will introduce 4 new packages to jdk, as usual packages via pkg review.

• java-1.8.0-openjdk-portable
• java-11-openjdk-portable
• java-17-openjdk-portable
• java-latest-openjdk-portable

Each of them will build jdk and jre in all three release,slowdebug,fastdebug. Release with zipped debuginfo, others with embedded. The resulting images will contain only tarball, and wide usage of them alone is not expected None of them will have any virtual provides.

In ideal world, we will build this only for oldest live Fedora, but tag for each version up.

Make the normal rpms to not built jdk, but to repack the portable rpms with all integration

This is most important step, without which it can be most likely dropped. We will stop building OpenJDK binary in java-x-openjdk packages %build. Instead we will BuildRequires: java-x-openjdk-portable, and we will just repack its content into java-x-openjdk to achieve full system integration. Such jdk rpms shodl be identical of those after step1.

It is essential, that only portables from oldest live fedora are used. Otherwise it would somehow work, but would be moreover useless.

This will again be system wide change, but with impact to all live fedoras once done.

Known issues

debuginfo

JDK is able to build with all necessary debuginfo and currently openjdk packages builds with proepr debuginfo packages. In case of portable tarball, we can produce correct external or internal debuginfo, but we are currenly unable to reuse this for debuginfo packages. As for future, we will most likely build slow and full debuginfo pkgs with embedded debuginfo. The release build may go out with ziped external debuginfo, or we wil find a way how to use that for creation of debuginfo rpms. If the reproducible builds will work in that time, we may use fourth build cycle to provide also release packages with embedded debuginfo, and then reuse this during repacking to create proper debuginfo