adjust rpms and (maybe) repositories so Temurin JDKs can serve as replacement of non-system JDKs in Fedora

[judovana]

Temurin SDKs as non-system JDKs in Fedora

The goal is to get rid of redundant maintenance of legacy JDKs in Fedora. And to keep legacy jdk support via temurin repositories https://adoptium.net/installation/linux/

This may be prequel to doing similar in RHELs

Prequel

JDK8 is slowly but surely disappearing. On enforced bytecode compatibility level, jdk21 - current system jdk in fedora - is the last one which supports jdk8 bytecode level. For jdk22 minimal bytecode level corresponds to jdk9. Next system jdk - 25 will be bytecode level compatible with jdk12. In addition, jdk11 and 17, do not carry the burden of backward compatibility as jdk8 does, and we can happily claim jdk21 would do.

All distribution people around OpenJDK have slowly moved towards the current reference implementation - Eclipse Adoptium Temurin JDK. Eclipse foundation is providing ecosystem for all possible distributions of JDK, from rpms and deb packages, over portable static tarballs to containers. As it is, it is win win for both users and developers. That includes also support tools like javaws or mission control (openjfx?)

Since jdk21, there is no room for any package to depend on jdk8, 11 and in year or so also on 17.

Thus we would like to continue to maintain future LTS - all STS java packages in rolling java-latest-openjdk, system JDK, and for short transition time previous STS (now 17), but we would lijke to drop all older jdks. Where there should be no lost for users, for developers, a comfortable dnf install java* is quite cool feature, and thus we would like to support this via eclipse temurin rpm repositories as an counter weight to SDKMAN and similar tools.

Known showstoppers

1. Versionless provides
   1. Each temurin RPM now has so-called version-less provides. Eg java or java-devel. In fedora and rhel, versionless provides are allowed only for system jdk. The jdk against which java-stack is built, and run, unless the maintainer or user says differently. JAVA_HOME should be always honoured (via javapackages-support). Alternatives are not honoured (javapackages-tools intentionally walk around alternatives setup)
   2. Proposed solution is to create a metapackage which will be providing the version-less provides. Such a package will not be shipped to repos offered to Fedora, but will be offered in current Temurin repos.
2. Eclipse Adoptium GB must agree with this apriory (possible work on their side, review headless subpackages, mera apckages, repo withtou version full metapackages…)

Known regressions

1. Headless subpackage is missing
   1. The headless subpackage do not depend on X stack, and are missing some jdk’s X libraries.
   2. Its functionality is verified by test-headless-components test
   3. Its creation in Temurin rpms should be easy.
      • **Disadvantage - **the filtering of files is manual work in spec files
   4. It is not a goal to create whole standalone (and TCKed) release of Temurins. To split final repacked JDK in specfile is the goal. When all the rpms are installed, TCK are passing (because repacked binary passed) and thus legal issues should be gone.
2. Architecture support
   6. Recently was added risc5 support to jdk11+ (on spec level)
   7. I’m not sure if Adotpium can cover all architectures.
   * But I think it don't matter

Proposed offering to fedora 41 system wide change

We will get rid of all non-system fedora/rpms/java-xy-openjdk once they stop being system JDK. As a start, we will discontinue JDKs 8 and 11 as follows:

1. We will simply orphan them, anybody can pick them up
   1. Kicks - as jdk 6 and 7 proved, it is impossible for single maintainer, even if deep in jdk development, seriously maintain OpenJDK packages
   2. They have to run TCK, otherwise there may come troubles
2. We will kill them, the rpms will make themselves obsolete by dummy readme or similar, and we will update fedora java page by “install temurin by adding this repo”
3. The rpms will replace themselves with repository file, and there will be proper obsolescence, so Temurin JDK(s) of proper versions will get transparently installed

This decision will flow up from the fedora-devel list and from fesco decision. If both will be strongly for the opinion (1), and indeed a strong maintainer would step in, and will prove themselves, then then we can add Temurins as secondary JDKs. This will be part of the proposal.

(3) is the preferred way to go, but we are not yet there.

To install 3rd party repository have exact rules:

1. Nothing is allowed to depend on it
2. Not the one who is proposing the change, but FESCO will contact the owners of the 3rd party repos

[jiekang]

To summarize, there are two requests for Adoptium to consider:

1. Blocker: Provide an RPM package that Provides specific versions of Java
2. Regression: Provide a headless RPM package.

What does this actually mean?

For 1. Provide an RPM package that Provides specific versions of Java

RPMs have a dependency mechanism using strings via Provides, BuildRequires, and Requires fields in the RPM spec file. For example: https://github.com/adoptium/installer/blob/master/linux/jdk/redhat/src/main/packaging/temurin/21/temurin-21-jdk.spec#L77

For some historical reason, Temurin RPMs do not specify a version in the provide field.

Provides: java

If we did, it would so look like:

Provides: java = 1:21.0.2.0.0.13-2.fc40

In comparison, other vendors like Amazon, Azul, and Red Hat, have explicit versions for their RPM's Provides fields.

Why does this matter?

The lack of a version is problematic. If Temurin 21 is installed on the system, and the Fedora user installs a package that needs JDK 8, then it would be satisfied by Temurin 21, but not actually work.

For 2. Provide a headless RPM package.

This is a subpackage in the same spec file that has a related files and dependencies removed to run in a headless environment with a smaller footprint.

For example:
Package defined in:
https://src.fedoraproject.org/rpms/java-21-openjdk/blob/rawhide/f/java-21-openjdk.spec#_1413
Files list defined in:
https://src.fedoraproject.org/rpms/java-21-openjdk/blob/rawhide/f/java-21-openjdk.spec#_2339
Which actually is defined in:
https://src.fedoraproject.org/rpms/java-21-openjdk/blob/rawhide/f/java-21-openjdk.spec#_799

[jiekang]

@judovana

Who will be using the headless packages? In the past we've had explicit requests for JRE packages, but I don't recall requests for headless packages. Are there many other packages in Fedora that depend on the headless package and can we see that list here? It would be nice to have some strong evidence for their benefit.

[jiekang]

@judovana

You mentioned a meta-package solution for the problem of versionless provides. Can you elaborate on what that looks like?

And I still do not fully understand: Why can't we just change all the spec files to Provides like:
Provides: java = 1:21.0.2.0.0.13-2.fc40

What is the danger of such a change? I appreciate your expertise here.

[sxa]

I have a few questions regarding the proposal:

Proposed solution is to create a metapackage which will be providing the version-less provides. Such a package will not be shipped to repos offered to Fedora, but will be offered in current Temurin repos.

Just to be clear - are you suggesting we change the current package to be versioned-only and then the metapackage would depend on the versioned one and "provide" the versionless one?
And

The rpms will replace themselves with repository file, and there will be proper obsolescence, so Temurin JDK(s) of proper versions will get transparently installed

Just to be 100% clear, does that mean that you'll replace the current java8,11,17 packages in Fedora with something that sets up the Temurin dnf repositories? And once that's done the user would be able to install temurin as a separate package? Or, since you've said it's transparent, would the Fedoras RPMs trigger the install as a postinstall step after setting up the temurin repos?

[judovana]

I will answer as soon as I can, bu those are not simple answer. One note on jdk8 and openjfx. In fedora we have opnejfx apckages whic are for jdk11 and up, those shoudl be worign wihtout issues. For jdk8, we ahd to add jdk8 subpackage, which added the necessary symlinks. This will disapear, but I think, we can already let openfx8 die in peace.

[judovana]

To summarize, there are two requests for Adoptium to consider:

1. Blocker: Provide an RPM package that Provides specific versions of Java

2. Regression: Provide a headless RPM package.

yes and yes. But introduction of headless subpackage is beneficial to all.

plus 3.regression is that javafx for jdk8, buthtat really do nto count at the end.
plus 4.regression lsot of shenandoah for jdk8, I guess thats ok too.

What does this actually mean?

For 1. Provide an RPM package that Provides specific versions of Java

RPMs have a dependency mechanism using strings via Provides, BuildRequires, and Requires fields in the RPM spec file. For example: https://github.com/adoptium/installer/blob/master/linux/jdk/redhat/src/main/packaging/temurin/21/temurin-21-jdk.spec#L77

For some historical reason, Temurin RPMs do not specify a version in the provide field.

Provides: java

If we did, it would so look like:

Provides: java = 1:21.0.2.0.0.13-2.fc40

In comparison, other vendors like Amazon, Azul, and Red Hat, have explicit versions for their RPM's Provides fields.

Why does this matter?

I'm not sure what version you now refer. I have never ever mentioned version behind versionless provides.
Whether you have

Provides: java

or

Provides: java = 1:21.0.2.0.0.13-2.fc40

Does not meter from my point of view. Still the second one is more correct, although we recenlty hit issue where versionless provides (eg java should not have the version string = 1:21.0.2.0.0.13-2.fc40. Unluckily this fix is not yetr in fedora, and in addtition our jira nd cgit is currently offline :-/ I need to double check this information before we progress.

Anyway the version-full , eg java-21-openjdk, provides must remain fully versiond by version string of = ....

The lack of a version is problematic. If Temurin 21 is installed on the system, and the Fedora user installs a package that needs JDK 8, then it would be satisfied by Temurin 21, but not actually work.

I'm again not sure what you mean by lack of version. Sorry.

The whole versionless x versionfull issue is based on java java-devel javadoc .... versus java-XY java-xy-devel javadoc-xy... See usage of is_system_jdk variable.

If the jdk is system jdk (is_system_jdk 1) then a version-less provides like java java-devel... are provided. If not ((is_system_jdk 0) then only version-full like java-XY java-xy-devel provides are provided.

The whole point is to distinguish system jdk against any other jdk. Only system jdk have versionless provides.
This allows us to move system jdk without touches to java aplications. This system have evolved in years, and is perfectly working.

You will hit the https://src.fedoraproject.org/rpms/java-21-openjdk/blob/rawhide/f/java-21-openjdk.spec#_393 and https://src.fedoraproject.org/rpms/java-21-openjdk/blob/rawhide/f/java-21-openjdk.spec#_921 and https://src.fedoraproject.org/rpms/java-21-openjdk/blob/rawhide/f/java-21-openjdk.spec#_1013 lines, which is making the issue a bit more tricky, but still proeprly doable.

If package requires some exact java, it requires it via java-xy... provides. But it is allowed only for special cases.

That is reason, why temurin jdks, when used in fedora, must not contain the versionless provides. Then exactly what you describe The lack of a version is problematic. If Temurin 21 is in... would happen.

Howeverm I think it is correct that each temurin jdk as it is now in generic repos, provides versionless provides like "java", as it is then trully versatile as any portbale package should be. If you decide to drop version-less provides completely, then we are done.

Pls consult also Deepak on this topic. it was moreover me an him behind this change, he may remember additional points

if not, a metapackage is here to help:

You mentioned a meta-package solution for the problem of versionless provides. Can you elaborate on what that looks like?

The metapackage is package with only with provides. Such package require the real package, which itself do not have the provides.

So in this exact scope it may be (but I hope it will be done better):

• current rpms will be renamed to be more fedora-friendly, and will drop versinless provides
• a metapackages, created as additional set of subpkgs in your spec, wil be generated. Each requiring one of above, and providing the versionless provides
• in your current repos both those sests will reside so the users will get transparent set of packages with allprovides
• second repo will be created, which will not contain the metapackages, so only version-full prvides will be provided by those packages.

If fedora frienldy names are no go, thats ok, virtual provides (which you afaik already have) would do. Only the meta packages will be weirdly named, and some rename of original packages is necessary anyway.

As your rpsm are "only" repacking tarball, maybe better then mtapackage is simply generate special set of rpms jsut for fedora, without versionless provides. As second repo is in play anyway.

And I still do not fully understand: Why can't we just change all the spec files to Provides like:
Provides: java = 1:21.0.2.0.0.13-2.fc40

Because it is not what I ment by versionless x versinfull ;)
Unluckily simple additon of version behind java do not solve the system jdk problem.
Pls consult with deepak if I'm not around, this is reallytricky issue "why we can not just add the version string behind versionless provides"

What is the danger of such a change? I appreciate your expertise here.
Of added version string? Unluckily simple additon of version behind java do not solve the system jdk problem.
Of meta package? No danger, only maintenance burden.

For 2. Provide a headless RPM package.

This is a subpackage in the same spec file that has a related files and dependencies removed to run in a headless environment with a smaller footprint.

For example: Package defined in: https://src.fedoraproject.org/rpms/java-21-openjdk/blob/rawhide/f/java-21-openjdk.spec#_1413 Files list defined in: https://src.fedoraproject.org/rpms/java-21-openjdk/blob/rawhide/f/java-21-openjdk.spec#_2339 Which actually is defined in: https://src.fedoraproject.org/rpms/java-21-openjdk/blob/rawhide/f/java-21-openjdk.spec#_799

Right. better view on that is, what files are not in headless one: https://src.fedoraproject.org/rpms/java-21-openjdk/blob/rawhide/f/java-21-openjdk.spec#_791

Only rpm generated requires on those .so are half a gig at least. And thats answers also:

Who will be using the headless packages? In the past we've had explicit requests for JRE packages, but I don't recall requests for headless packages. Are there many other packages in Fedora that depend on the headless package and can we see that list here? It would be nice to have some strong evidence for their benefit.

The user is anybody who do not want to mess its system by X and other windowing depndecs, no metter what reason it is. Cool example is any build system. But unluckily java-devel rewuires full jre, not jsut jre-headless.
java-headless is actually a default requires anybody should use, unless they really requires X for rutime. So the answer for you is every deployment and every cli user who do not need devel which is quite a lot.

[judovana]

I have a few questions regarding the proposal:

Proposed solution is to create a metapackage which will be providing the version-less provides. Such a package will not be shipped to repos offered to Fedora, but will be offered in current Temurin repos.

Just to be clear - are you suggesting we change the current package to be versioned-only and then the metapackage would depend on the versioned one and "provide" the versionless one? And

Correct. For details see my answer to Jie.

The rpms will replace themselves with repository file, and there will be proper obsolescence, so Temurin JDK(s) of proper versions will get transparently installed

Just to be 100% clear, does that mean that you'll replace the current java8,11,17 packages in Fedora with something that sets up the Temurin dnf repositories? And once that's done the user would be able to install temurin as a separate package? Or, since you've said it's transparent, would the Fedoras RPMs trigger the install as a postinstall step after setting up the temurin repos?

it can be both, and depends on our agreement.

Smallest intervention - I will just discontinue jdk8,11 and in a year also 17 and will enhance fedora java pages so they recommend to install temurin jdk. With link to temurin pages.

Bigger intervention - I will replace jdk 8,11 and later 17 really by the repository file, but will not transparently allow update to temurins. This and additional steps will be documented in fedora-java pages.

Total intervention. I will replace jdk 8,11 and later 17 really by the rrepository file, and will set up proper obsoleted by in my rpms and/or proepr provides in temurins so it will allow transaprent update to temurins. I guess It will be also documented in fedora-java pages.

I see the last as best, but it is also on FESCO and fedora-devel discussion. And of course Temurin people .

If third will be the option, then I do not plan to do this in posttrans. I plan to add the repository in one transaction, and later to remove myslef and substitue by temurins.

[judovana]

I had jsut realised that jdk8 will lost also shenandoah, but I guess thats ok.

Is jdk11 built with shenandoah enabled? Upstreamis, so I guess it is.. Please correctme

[jiekang]

Thank you Jiri for clarifying. Sadly the GH Comment UI is not that great for replying in-line as it gets longer as longer :( I wonder if there is some other tool to help with that...

For 1. Provide an RPM package that Provides specific versions of Java

Okay. I'm glad you've clarified further as I misunderstood the request. A concrete example would have been nice in the initial request.

So, what is actually requested:

Before:

Provides: java
...

After:

Provides: java-21
...

Before continuing further discussion, is this correct? I think so as now all your other comments make complete sense in this context :)

The term version-less provides was confusing. I thought you were referencing the = 1:21.0.2.0.0.13-2.fc40 portion of the Provides field as that is a version, and we do not have that, therefore it is version-less.

[judovana]

Thank you Jiri for clarifying. Sadly the GH Comment UI is not that great for replying in-line as it gets longer as longer :( I wonder if there is some other tool to help with that...

For 1. Provide an RPM package that Provides specific versions of Java

Okay. I'm glad you've clarified further as I misunderstood the request. A concrete example would have been nice in the initial request.

yah, reading it, now, with this ponit of view on, I should be more specific, but the issue is so obvious to me:( Really sorry.

So, what is actually requested:

Before:

Provides: java
...

After:

Provides: java-21
...

Before continuing further discussion, is this correct? I think so as now all your other comments make complete sense in this context :)

yes.

It contains also various:

Provides: jre-21
Provides: jre-21-temurin
Provides: jre-21-openjdk
Provides: java-21
Provides: java-sdk-21-temurin
Provides: java-sdk-21-openjdk
Provides: java-sdk-21
Provides: java-21-devel
Provides: java-21-temurin-devel
Provides: java-21-openjdk-devel
...

I recommend, that all version-full provides contains full version string = %{epoch}:%{version}-%{release}

The term version-less provides was confusing. I thought you were referencing the = 1:21.0.2.0.0.13-2.fc40 portion of the Provides field as that is a version, and we do not have that, therefore it is version-less.

Correct. In my vocabulaty thet = 1:... is version string. Sorry for confusion. Am happy it was cleared at the end.

[judovana]

Does not meter from my point of view. Still the second one is more correct, although we recenlty hit issue where versionless provides (eg java should not have the version string = 1:21.0.2.0.0.13-2.fc40. Unluckily this fix is not yetr in fedora, and in addtition our jira nd cgit is currently offline :-/ I need to double check this information before we progress.

here is the jira: https://issues.redhat.com/browse/OPENJDK-2507

The "provides" value has changed in java-1.8.0-openjdk-headless.x86_64,
version 1:1.8.0.392.b08-2.el7_9, rpm.
Previous versions of this package listed "java-headless = 1:1.8.0", and
u392 has a specific minor version tied to it: "java-headless =
1:1.8.0.392.b08-2.el7_9".
The result is that third-party packages that require specifically
"java-headless 1:1.8.0" are not compatible with the new version 392.

As this revert goes only to old rhels, not to the future, temurins should use full version string also for versionless provides.

[jiekang]

Thanks @judovana for all your follow ups. The explanations make sense to me. Delivering headless subpackages seems generally worthy as it will strengthen our offerings. Our installers in general do need some love...

Smallest intervention - I will just discontinue jdk8,11 and in a year also 17 and will enhance fedora java pages so they recommend to install temurin jdk. With link to temurin pages.

Bigger intervention - I will replace jdk 8,11 and later 17 really by the repository file, but will not transparently allow update to temurins. This and additional steps will be documented in fedora-java pages.

Total intervention. I will replace jdk 8,11 and later 17 really by the rrepository file, and will set up proper obsoleted by in my rpms and/or proepr provides in temurins so it will allow transaprent update to temurins. I guess It will be also documented in fedora-java pages.

For the three levels of intervention, in the case of the smallest/bigger, is a fix for the Provides necessary? It sounds like it would be necessary for the total intervention case at least.

The Temurin RPM already clashes with the system JDK in Fedora today, right? So the motivation to fix it is that, after your change in Fedora, more users will be using Temurin on Fedora systems and the problem will likely be seen more often. Just checking, are there any other motivations for the change?

[judovana]

I think the removal of versionless provides is mandatory in all three cases (moreover as you summ up in last paragraph).

Moreover expected case:

• some special usecase requires legacy, eg jdk8, on jdk-free fedora isntallation
• as recomanded in guidelines, user installs temurin8
• all good
• system stops to be jdk-free, once user install some repositories based java application
• system jdk will not be installed as temurin8 provides versionless provides.
• new application will die with some reasonable exceptrion or with invalid bytecode level

Unexpected case:

• lets have regular fedora installation
• during its lifetime, user installs any temurin jdk
• during system update to next Fedora, where system jdk changed, theirs system jdk will not be updated, becasue temurin provides versionless provides.
  • where original system jdk lost them, and remained updated on disk
  • the new one, which started to get them, will not be pulled to transaction, because temruin is satisfying system jdk update provides