Comments (11)
- 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.
from installer.
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 namejava
here is being used to refer to the RPM package metadata, not thejava
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 thejava
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 providingjava
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 seenTrue 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 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.Provides: java-XX-openjdk
which we do not currently do
from installer.
@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.
from installer.
All versionless provides must be removed - java, javac, I have to double check it.
No, keeping/adding the version would not help:(
from installer.
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
from installer.
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..)
from installer.
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 ;-)
from installer.
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.
from installer.
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 existingtemurin-XX-jdk
and adds theProvides: java
andRequires:
the other one. - Fedora could consider not relying on
java
as being the system JDK as it is currently defined and use thejavapackage-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 JDK21proguard
pulls in the system java-21-openjdk-headless even if Temurin 21 is installed (But temurin-21-jdk will satisfy it) - it depends onjavapackages-tools
which requires java-21-openjdk-headless (Intriguingly if the corretto repos are enabled it tries to pull in bothjava-21-openjdk-headless
andjava-23-amazon-corretto-devel
... If I install an old temurin e.g.temurin-11-jdk
then that stops it pulling in thejava-23-amazon-corretto-devel
package ... I can only assume this is related to thejava >= 1:1.6.0
which proguard has in addition tojavapackages-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 :-)
from installer.
* 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?
from installer.
I have the proposal already done, to amned it with this change is simple.
from installer.
Related Issues (20)
- Packaging process does not work correctly for RPMs, when dist = all
- Windows ARM64 binaries are being installed to incorrect location
- Test
- April 2024 - Unix Installer Packages Release Tracker HOT 1
- Generated MSIs lack end-user license agreement HOT 10
- Alpine temurin ARM64 Package depends on x86 Package HOT 9
- GPG Signing Fails For RHEL Installer Packages HOT 1
- Origin/Label for Debian repositories
- add headless subpackage
- add aarch64/shenandoah support for jdk8
- provide slowdebug and fastdebug subpackages
- contact fesco
- No release for Ubuntu mantic HOT 2
- add javadoc subpackages
- Why is debian apt install so much larger than the JDK release binary? HOT 2
- ,<%3%&+() HOT 1
- July 2024 CPU - Unix Installer Packages Release Tracker HOT 1
- JRE RPM package is not signed HOT 12
- pkgbuild GH action fails for latest Java 8 due to naming of package
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from installer.