remove versionless provides from rpm builds

[judovana]

This issue was pinpointed as show-stopper in #848

The versionless provides are blocker for any fedora/rhel like distribution to use temurins instead or in-disro rpms.
The reason is, that versionless provides are suppose to be only for system jdk - the jdk which builds and runs distribution java stack.

If versionless provides can not be removed, then - to achive adjust rpms and (maybe) repositories so Temurin JDKs can serve as replacement of non-system JDKs in Fedora soem repo magic will need to be don (or simply build special set of rpms, which is scary). The meta package repo-magic workaround is like: original temurin repo will contain both meta packages (with versionless provides, which just requires versionless-free normal packages. Tehn for fedora is creatyed repo which contains only versionless-free normal pcakages.

More detailed info in #848

@jiekang fyi!

[sxa]

I think we should aim to do versionless provides as a resolution here and attempt to progress on that basis. Based on the summary analysis at #848 (comment) the TL;DR for the PMC is as follows:

• RPM distributions often expect that packages that require java (the name java here is being used to refer to the RPM package metadata, not the java command) is what we're calling a "versionless provide" (since it is not qualified with a version number) will have the version which is considered the default distribution for the distro available if a package meeting the java requirement is installed. This can be different on different distributions depending on the decision made at the time the distribution was shipped.
• When a Temurin RPM is installed, it installs itself as the default java without taking into account the above, and means that the Temurin RPMs could break distribution-supplied applications relying on the package providing java being a particular version.
• The risk of this is that Temurin users may be relying on this functionality and expect our RPMs to "Provide java", but I think the risk of destabilising someone's machine when dropping in Temurin as a replacement is potentially a larger concern.
• Making this change would be consistent with how other providers such as Amazon and Azul ship their rpms from what I've seen True for Azul, not for Amazon
• An alternative option would be to have a separate .rpm for Fedora which removes the "versionless provides" (since we have separate ones for RH/SuSE already) but I'd rather not maintain more of them...

The ask here is therefore for approval to remove the Provides: java line and add in Provides: java-XX-openjdk which we do not currently do in order to be able to act as a drop-in replacement for any OS-provided version of java. The implementation details can be left to discussion in this PR if that decision is approved.

[judovana]

• an alternative option would be to have a separate .rpm for Fedora which removes the "versionless provides" (since we have separate ones for RH/SuSE already) but I'd rather not maintain more of them...

Alternative to this may be already described metapackage workaround. That version-less provides are provided by metapackage, which weil not be avialable in the fedora respo. This preventing existence of another set of RPMs, but is adding a bit of repository logic.

[sxa]

@judovana Just to confirm since I've been looking closer at some of the packages again. I wrote this above:

The ask here is therefore for approval to remove the Provides: java line

Would it be feasible to retain the java provides if it had a version number associated with it? (Temurin's one currently doesn't which would seem to have been an oversight) or would that be a problem for other reasons.

[judovana]

All versionless provides must be removed - java, javac, I have to double check it.
No, keeping/adding the version would not help:(

[sxa]

All versionless provides must be removed - java, javac, I have to double check it. No, keeping/adding the version would not help:(

That's what I expected you to say so thanks for confirming :-) I looked at one example java application in the F40 repos (tomcat - the first that came to mind) and it seemed to have a dependency on either the headless packages or java >= 1.8

[root@ef1c1b0ecdcb /]# dnf repoquery --requires tomcat
Last metadata expiration check: 0:00:51 ago on Thu Jun 27 16:01:22 2024.
(java-headless >= 1:1.8 or java-1.8.0-headless or java-11-headless or java-17-headless or java >= 1:1.8)

I was expecting it to need the system one explicitly. Impressive that it still runs on 8 (assuming the dependencies are valid of course ;-) ).

[EDIT: Interestingly temurin-8-jdk does NOT satisfy the prereqs for tomcat which still tries to install java-21-openjdk-headless- perhaps because we provide java without an explicit version and it needs >=1:1.8. Are there examples packages in Fedora where a Temurin install would override the system one?]

[EDIT 2: This is interesting because java-1.8.0-headless is listed as a valid dependency of tomcat and that is satisfied by temurin-8-jdk however tomcat has an additional dependency on javapackages-tools which DOES have a hard dependency on java-21-openjdk-headless (Not java) which temurin-21-jdk provides ]

[root@ef1c1b0ecdcb /]# dnf install java-1.8.0-headless
Last metadata expiration check: 0:09:16 ago on Thu Jun 27 16:05:30 2024.
Package temurin-8-jdk-8.0.412.0.0.8-1.x86_64 is already installed.

[root@ef1c1b0ecdcb /]# dnf repoquery --requires javapackages-tools
Last metadata expiration check: 0:19:49 ago on Thu Jun 27 16:05:30 2024.
coreutils
findutils
java-21-openjdk-headless
javapackages-filesystem = 6.2.0-9.fc40
which

[judovana]

java >= 1:1.8 and java-headless >= 1:1.8 ... Ok. The version in versionless provides will not help, butdo not hurt. Sorry for not being clear imediately.. We ahve it here: https://src.fedoraproject.org/rpms/java-21-openjdk/blob/rawhide/f/java-21-openjdk.spec#_1120

Funnily enough, there was up to recently generator of amven provides: which was generating requires with all version-full(!!) requires. And it is leaving just now: https://fedoraproject.org/wiki/Changes/Drop_Mandatory_Requires_on_JRE

I will need to double check this tomorrow morrning in fresh condition, but the acording to that code snippets, temurin jdk8 shares some provides with java-1.8.0-headless (which is a bit weird, as it do not provide java-1.8.0-headless and thus distribution jdk8 shodl be installed anyway..)

[sxa]

I will need to double check this tomorrow morrning in fresh condition

Good plan - I definitely feel my brain needs until tomorrow to process all the possibilities too ;-)

[sxa]

It sounds like there have been a number of changes in Fedora 41 that will make some of these requirements more consistent so Fedora 40 may not be the best place to investigate things :-)

Noting that some of the other distributions do provide java with a version number (the last of these is the Fedora-supplied one). Amazon Corretto and Bellsoft Liberica would replace the system JDK by providing java in the same way as Temurin currently does (Same is true of their JDK11):

[root@e2d33ee9e0b3 /]# for JDK in temurin-21-jdk zulu21-jdk java-21-amazon-corretto-devel bellsoft-java21 java-21-openjdk; do echo ==== $JDK; rpm -q --provides $JDK | grep '^java' | grep -v ^java- ; done 
==== temurin-21-jdk
java
==== zulu21-jdk
==== java-21-amazon-corretto-devel
java = 1:21.0.4.7-1
==== bellsoft-java21
java = 21.0.4.0.0.9
==== java-21-openjdk
java = 1:21.0.4.0.7-2.fc40

Also noting that bellsoft-java11 provides java = 11.0.24+9 which is a format I haven't seen elsewhere so far.

[sxa]

Some further investigation shows that while zulu21-jdk does not provide java as per the previous comment, a dependent package of it (zulu21-ca-jre-21.0.4-1.x86_64) does which has some additional so libraries such as libawt_xawt.so) does do so, so this change would mean that Temurin was different from everyone else. Also noting that the direct rpm download from Azul for 21.0.3 is a standalone package which does not require the others and does provide java.

This makes it harder to justify making this change since it would be a behavioral difference between Temurin and most other providers outside those of the OS.

Two potential options at this point if we will not progress with the original plan:

• Continue with the proposed change to remove the Provides: java from the base package but create a second package that depends on our existing temurin-XX-jdk and adds the Provides: java and Requires: the other one.
• Fedora could consider not relying on java as being the system JDK as it is currently defined and use the javapackage-tools instead to explicitly mean the system JDK. Note that this solution would not impact existing LTS releases such as the EL distributions which are based on the old method (although they are already potentially impacted, and we haven't had any concerns reported so maybe that's a risk we can still take). @judovana is having some discussions to look at the feasibility of this option.

Some extra notes coming out of my experiments this week: The packages in Fedora 41 currently have a mix on what they depend on e.g.:

• sdljava is happy with temurin-11-jdk as a prereq (It doesn't seem to require 21) so I guess that shows the problem we're looking at resolving since it depends on java It also needs javapackages-filesystem but not javapackages-tools which would force the installation of JDK21
• proguard pulls in the system java-21-openjdk-headless even if Temurin 21 is installed (But temurin-21-jdk will satisfy it) - it depends on javapackages-tools which requires java-21-openjdk-headless (Intriguingly if the corretto repos are enabled it tries to pull in both java-21-openjdk-headless and java-23-amazon-corretto-devel ... If I install an old temurin e.g. temurin-11-jdk then that stops it pulling in the java-23-amazon-corretto-devel package ... I can only assume this is related to the java >= 1:1.6.0 which proguard has in addition to javapackages-tools
• testng appears to only have a dependency on javapackages-filesystem so doesn't explicitly pull in any JDK package if none is already installed, which feels like a bug :-)

[judovana]

* Fedora could consider not relying on `java` as being the system JDK as it is currently defined and use the `javapackage-tools` instead to explicitly mean the system JDK. Note that this solution would not impact existing LTS releases such as the EL distributions which are based on the old method (although they are already potentially impacted, and we haven't had any concerns reported so maybe that's a risk we can still take). @judovana is having some discussions to look at the feasibility of this option.

First of all, I personally very like this solution. I 'm perplexed we had not come with it out for start.
I had chat with people around javapackage-tools (@mkoncek) and they quite like the idea. It seems to be aligned wit their's f41 proposal to drop generated provides (aleary done - https://fedoraproject.org/wiki/Changes/Drop_Mandatory_Requires_on_JRE)

It is quite common that system wide change will do some mass-sed of provides/requires in related packages. In our case, from aprox 400pkgs we rebuild during system jdk bump, only aprox 50 requires java/java-devel. Others have it through transitive dependence, mostly javapackage-tools already.

There will be only one todo on javapackage-tools side - to somehow susbtite java-devel requires for programs build directly by javac. Thats on shcedule for tomorrow/friday.

javapackage-tools already now handles system jdk, and for each system jdk change a commit is needed to them anyway. I belive, that this change may do it to el10. @neugens @dbhole wdyt?

[judovana]

I have the proposal already done, to amned it with this change is simple.

[judovana]

We have agreed to not drop the provides. and change how fedora deals with it.