bell-sw / Liberica

Free and 100% open source Progressive Java Runtime for modern Java™ deployments supported by a leading OpenJDK contributor
https://bell-sw.com/pages/libericajdk/
GNU General Public License v2.0
312 stars 29 forks source link

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

Open long76 opened 2 years ago

long76 commented 2 years ago

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 commented 1 year ago

@morgion @PakhomGolynga please read issue. thanks!

voitylov commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

long76 commented 1 year ago

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.