Comments (24)
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.
from installer.
To summarize, there are two requests for Adoptium to consider:
- Blocker: Provide an RPM package that Provides specific versions of Java
- 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
from installer.
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.
from installer.
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.
from installer.
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?
from installer.
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.
from installer.
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.
from installer.
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
from installer.
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.
from installer.
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.
from installer.
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.
from installer.
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?
from installer.
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
from installer.
Okay. Thanks for those two examples @judovana, that is really helpful to understand. So reviewing this in whole, I see two different parts.
-
The headless subpackage. I do not think this requires a full PMC review. It would be an additional feature that strengthens our installer offering and does not have any compatibility issues for existing users.
-
The versionless provides. The manner in which we implement this will impact existing users. We should have a PMC review before proceeding.
Lets continue to discuss versionless provides here and put the headless feature into it's own issue.
from installer.
Note, that this issue should serve to find all possible issues in both Temurin JDK and in Fedora, so that the feature can happen at all.
If we agreed both headless subpackage and versionless provides should happen, then they both desrve its own issue, and we can continue here to search for other issue, or disucss them there as they will be occuring once it it made more public
from installer.
Note, that this issue should serve to find all possible issues in both Temurin JDK and in Fedora, so that the feature can happen at all.
If we agreed both headless subpackage and versionless provides should happen, then they both desrve its own issue, and we can continue here to search for other issue, or disucss them there as they will be occuring once it it made more public
Okay, makes sense. Let's follow this approach then. Do you see any other areas to investigate for issues with Temurin and Fedora?
from installer.
Nope, But I'm pretty sure they will emerge:(
from installer.
Good to see the discussion taking place here. I'm going to remove the PMC tag for this specific issue as it is getting long, and ask that we open associated specific focused issues for decisions concluded here that need to go to PMC review. There is no rush for these.
from installer.
This is quite long but I'm adding in this comment as a summary for my own benefit and for anyone else reading it as an explanation of the concern with what Temurin currently does that blocks Fedora using our rpm files. This is specific to the versioning and does NOT cover any discussion relating to headless.
Fedora is considering removing their older openjdk packages and encouraging users to move to Temurin instead. They have a number of options for this, however a blocker to any user migration story is that they need RPM packages that Provides specific versions of Java and do not Provide: java
which the current temurin ones do (See Temurin redhatspec file)
Fedora expects that any package which satisfies the requirement for java
will be the one that was typically the latest java LTS specification (Currently java 21) at the time of the release of that distribution and therefore it would be inappropriate for any earlier (or later) implementation to be advertising itself as providing java
to the system. They would like Temurin to only provide java-21
and similar and not a default java
implementation from the package manager's perspective.
To see the concern in action, running rpm -q provides java
on a recent Fedora system (e.g. 40 - if you're using something pre-dnf then yum whatprovides java
will give the same information) will show this - note that the java-17-openjdk
and other earlier versions are not shown in this list:
java-21-openjdk-1:21.0.2.0.13-3.fc40.aarch64 : OpenJDK 21 Runtime Environment
Repo : fedora
Matched from:
Provide : java = 1:21.0.2.0.13-3.fc40
If you add in the Temurin repositories there will be entries for all of the different versions available from Temurin, which is in conflict with the Fedora requirements.
Output from `dnf -q provides java` with Temurin repository enabled
java-21-openjdk-1:21.0.2.0.13-3.fc40.aarch64 : OpenJDK 21 Runtime Environment
Repo : fedora
Matched from:
Provide : java = 1:21.0.2.0.13-3.fc40
java-21-openjdk-1:21.0.3.0.9-1.fc40.aarch64 : OpenJDK 21 Runtime Environment
Repo : updates
Matched from:
Provide : java = 1:21.0.3.0.9-1.fc40
temurin-11-jdk-11.0.23.0.0.9-1.aarch64 : Eclipse Temurin 11 JDK
Repo : Adoptium
Matched from:
Provide : java
temurin-17-jdk-17.0.11.0.0.9-1.aarch64 : Eclipse Temurin 17 JDK
Repo : Adoptium
Matched from:
Provide : java
temurin-21-jdk-21.0.3.0.0.9-1.aarch64 : Eclipse Temurin 21 JDK
Repo : Adoptium
Matched from:
Provide : java
temurin-22-jdk-22.0.1.0.0.8-1.aarch64 : Eclipse Temurin 22 JDK
Repo : Adoptium
Matched from:
Provide : java
temurin-8-jdk-8.0.412.0.0.8-1.aarch64 : Eclipse Temurin 8 JDK
Repo : Adoptium
Matched from:
Provide : java
Some notes:
- The earlier Fedora java-NN-openjdk packages do still install themselves as
java
in /etc/alternatives/java etc. but will be overridden if you subsequently install the "system" JDK of 21. By contrast if you have, for example, Fedora's JDK17 installed and then install temurin-8-jdk the the defaultjava
will become Temurin 8 and attempts to rundnf install java
will not result in JDK21 being installed (because temurin-8-jdkProvides: java
), which is likely to break dependencies for products expectingjava
to be 21 on that distribution. Fundamentally it's a problem with consistency. - While I've given examples for Fedora 40, for other distributions the "expected" package that
Provides: java
may be different so just saying "The latest LTS can haveProvides: java
" is not appropriate as a solution here. For example on UBI9 it is java 11, and while they have later versions in the repository they do not haveProvides: java
and java 11 overrides 17 as the default on that distribution. Currently Temurin will always override the default regardless of which version is installed because itProvides: java
- The "system" JDK version in Fedora is done with the
is_system_jdk
variable in their spec files e.g. java-17 and java-21 - There is a section in the spec files that choose whether to provide
java
based on this value:
Provides: java-%{origin}%{?1} = %{epoch}:%{version}-%{release}
Provides: jre-%{origin}%{?1} = %{epoch}:%{version}-%{release}
Provides: java%{?1} = %{epoch}:%{version}-%{release}
Provides: jre%{?1} = %{epoch}:%{version}-%{release}
%endif
The concern from a Temurin perspective is that this cannot be replicated with a single RPM (Since the distribution determines which one is the "system" JDK and Temurin currently does not provide multiple RPMs for each distribution and I think we we would prefer not to start doing so, especially since we'd rather reduce the complexity of our uploads as per #501
Temurin does not currently have a Provides
for java-11-openjdk to work as a drop-in replacement (but we do provide java -11
so if there was a "shell" (metapackage?) java-11-openjdk package (and maybe even java
in a distribution-specific way) going forward that could be fulfilled by java-11
from Temurin that would allow it to be a drop-in replacement, other than the fact we still have Provides: java
(Not, that changing it to Provides: java = 21...
would not resolve the concern based on this comment)
While it's not directly related to the above, we should consider listing our Provides
lines with a specific version number in the Temurin spec files e.g. Provides: java-11 = 1:21.0.2.0.0.13-2
It has been noted that other vendors like Amazon, Azul, and Red Hat, have explicit versions for their RPM's Provides fields.
Noting also that Temurin currently provides separate rpm files in the repository for RHEL and SUSE. One option here would be to have a third option for Fedora with an alternative setup (which would remove any backwards compatibility concerns for Temurin users, although as noted above UBI (And therefore presumably RHEL) would have the same concern so adjusting for the existing rhel
version may be appropriate. The difference being that Temurin is not being considered as the default implementation for anything other than Fedora.
from installer.
true
from installer.
* The "system" JDK version in Fedora is done with the `is_system_jdk` variable in their spec files e.g. [java-17](https://src.fedoraproject.org/rpms/java-17-openjdk/blob/rawhide/f/java-17-openjdk.spec#_94) and [java-21](https://src.fedoraproject.org/rpms/java-21-openjdk/blob/rawhide/f/java-21-openjdk.spec#_94) * There is a section in the spec files that choose whether to provide `java` based on this value:
Provides: java-%{origin}%{?1} = %{epoch}:%{version}-%{release} Provides: jre-%{origin}%{?1} = %{epoch}:%{version}-%{release} Provides: java%{?1} = %{epoch}:%{version}-%{release} Provides: jre%{?1} = %{epoch}:%{version}-%{release} %endif
The concern from a Temurin perspective is that this cannot be replicated with a single RPM (Since the distribution determines which one is the "system" JDK and Temurin currently does not provide multiple RPMs for each distribution and I think we we would prefer not to start doing so, especially since we'd rather reduce the complexity of our uploads as per #501
I would be actually quite happy to include this variable and its usage into Temrun's specfiles. Only it will remain for ever false.
from installer.
I would be actually quite happy to include this variable and its usage into Temrun's specfiles. Only it will remain for ever false.
🤔 I quite like that idea ... It would also give anyone else who wanted to the ability to create an rpm using our scripts with the option turned on if they wanted to. (I guess it could also be a list that has the version(s) that can act as system ones but that's maybe more complex than would be required). I think from the Adoptium perspective at this point it's a question of "Are we happy with this being off by default?" and go from there.
(And with that, I'm shutting the laptop down until June! See you all next month)
from installer.
think from the Adoptium perspective at this point it's a question of "Are we happy with this being off by default?" and go from there.
Exactly. Happy vacation!
from installer.
I had created all pinpointed subissues:
- remove versionless provides from rpm builds
- add headless subpackage
- add aarch64/shenandoah support for jdk8
- provide slowdebug and fastdebug subpackages
- add javadoc subpackages
- contact fesco
from installer.
Related Issues (20)
- Support for new distributions - April 2024 HOT 4
- 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
- remove versionless provides from rpm builds HOT 9
- 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
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.