Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jdk 8 deb package do not provide java8-runtime-headless #91

Open
long76 opened this issue Aug 1, 2022 · 9 comments
Open

jdk 8 deb package do not provide java8-runtime-headless #91

long76 opened this issue Aug 1, 2022 · 9 comments

Comments

@long76
Copy link

long76 commented Aug 1, 2022

Hello, i moved from Azul Zulu JDK 8 to yours BellSoft JDK 8.
Kubuntu 20.04
Install command "sudo apt install bellsoft-java8-full"
Try install "ca-certificates-java" but it's install openjdk from system repository.
Command "apt-cache show ca-certificates-java":
Depends: ca-certificates (>= 20121114), default-jre-headless | java8-runtime-headless, libnss3 (>= 3.12.9 ckbi-1.82-0ubuntu3~)

Command "apt-cache show bellsoft-java8-full":
Provides: java8-jdk, java8-sdk, java7-jdk, java7-sdk, java6-sdk, java5-sdk, java2-sdk, java-sdk, java-compiler, java8-runtime, java7-runtime, java6-runtime, java5-runtime, java2-runtime, java-runtime, openjfx

Please add "java8-runtime-headless" in provides for packages. Thanks!

@long76 long76 changed the title jdk 8 deb do not provide java8-runtime-headless jdk 8 deb package do not provide java8-runtime-headless Aug 1, 2022
@long76
Copy link
Author

long76 commented Nov 24, 2022

@morgion @PakhomGolynga please read issue. thanks!

@voitylov
Copy link
Collaborator

I guess this is by design, and users should not be confusing headless and headful binaries. The publicly available Liberica binaries are headful, so adding a -headless tag would cause confusion.

Headless builds can't be derived from headful builds. It requires a differently compiled JDK binary, which is (currently) only available for customers.

To check if the build is indeed headful or headless, we embed java.awt.headless=true property.

@long76
Copy link
Author

long76 commented Jan 19, 2023

I guess this is by design, and users should not be confusing headless and headful binaries. The publicly available Liberica binaries are headful, so adding a -headless tag would cause confusion.

Headless builds can't be derived from headful builds. It requires a differently compiled JDK binary, which is (currently) only available for customers.

To check if the build is indeed headful or headless, we embed java.awt.headless=true property.

i see seems need update dependencies in ca-certificates-java

@voitylov
Copy link
Collaborator

Liberica standard packages do not depend on system certificates on Linux, Liberica maintains its own cacerts which includes most common certificates. This is done for consistency across the platforms Liberica supports (Mac, Windows, Solaris, etc). User certificates can be added using JKS and keytool, which are also uniform across platforms. So, from a position of a distribution that has to act uniformly on all platforms and Linux flavors, it's best not add such dependencies.

On the other hand, we will provide such tight integration between the JDK and system certificates in Alpaquita. This will come with the ability to maintain user certificates which will survive system certificates updates.

@long76
Copy link
Author

long76 commented Jan 19, 2023

Liberica standard packages do not depend on system certificates on Linux, Liberica maintains its own cacerts which includes most common certificates. This is done for consistency across the platforms Liberica supports (Mac, Windows, Solaris, etc). User certificates can be added using JKS and keytool, which are also uniform across platforms. So, from a position of a distribution that has to act uniformly on all platforms and Linux flavors, it's best not add such dependencies.

On the other hand, we will provide such tight integration between the JDK and system certificates in Alpaquita. This will come with the ability to maintain user certificates which will survive system certificates updates.

but i have to use keytool on jdk cacerts and in next update jdk cacerts will be override from install package and needed add my own CA again

ca-certificates-java give ability to add/update ca certs. in some case needed use only specifed JDK version and update certificate independely without editing JDK package

@den1ska
Copy link
Collaborator

den1ska commented Jan 19, 2023

What if you simply drop $JAVA_HOME/lib/security/cacerts and make it a symlink to /etc/ssl/certs/java/cacerts? If I'm not wrong, you will get a file conflict during the next update but your symlink will survive.

@long76
Copy link
Author

long76 commented Jan 19, 2023

What if you simply drop $JAVA_HOME/lib/security/cacerts and make it a symlink to /etc/ssl/certs/java/cacerts? If I'm not wrong, you will get a file conflict during the next update but your symlink will survive.

i think yes it's may works

@long76
Copy link
Author

long76 commented Aug 1, 2023

deb package use /etc/ssl/certs/java/cacerts if it exists?

@long76
Copy link
Author

long76 commented Aug 1, 2023

from readme ca-certificates-java

This package uses the hooks of the ca-certificates package to update the JKS
keystore /etc/ssl/certs/java/cacerts used for many java runtimes. The alias used
to store the certificate is the basename prefixed with 'debian:'. It will import
all *.pem files found in /etc/ssl/certs during its first installation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants