GoCD 24.1.0 forced package dependency on OpenJDK17 JRE makes it difficult to BYO JRE

[tewfik-ghariani]

Issue Type

• Bug Report

Summary

go-server package v24.1.0 has now a forced dependency on openjdk-17-jre-headless

Previous versions had no explicit dependencies and we have been using it with a "Temurin" installation

Environment

Basic environment details

• Go Version: 23.5.0 (18179-7702b283accd1f90f014f0087aa2e9bd8baf4a97) at the moment
• JAVA Version: 17.0.11
• OS: Linux 6.1.0-21-amd64
• Browser vendor and version (if relevant): Not relevant

Steps to Reproduce

This shows the list of dependencies of the go-server package, it wasn't relying on any specific jdk/jre

⚡root@gocd-server:~$ ⚡ apt show go-server -a | grep -E 'Version|Depends'

Version: 24.1.0-18867
Depends: coreutils, procps, openjdk-17-jre-headless
Version: 23.5.0-18179
Depends: coreutils, procps
Version: 23.3.0-16991
Depends: coreutils, sysvinit-utils, procps, login

This specific package depends on ca-certificates-java which is purged in our setup due to old java versions, thus breaking the go-server unit

⚡root@gocd-server:~$ ⚡ apt show openjdk-17-jre-headless  -a | grep -E 'Version|Depends' | grep ca-certificates-java --color

Depends: ca-certificates-java (>= 20190405~), java-common (>= 0.28), libcups2, libfontconfig1, liblcms2-2 (>= 2.2+git20110628), libjpeg62-turbo (>= 1.3.1), libnss3 (>= 2:3.17.1), util-linux (>= 2.26.2-4), libasound2 (>= 1.0.16), libc6 (>= 2.34), libfreetype6 (>= 2.3.5), libgcc-s1 (>= 3.0), libharfbuzz0b (>= 1.2.6), libpcsclite1 (>= 1.3.0), libstdc++6 (>= 5), zlib1g (>= 1:1.2.2)

Expected Results

No explicit dependency on JDK/JRE should be set

Possible Fix

Users can install the JDK of their choice

[chadlwilson]

Hiya - yeah, this is/was intentional, to resolve #11354. GoCD for a long time bundled its own JRE (Temurin) but it did so incorrectly, bundling an x64 JRE with an arch independent package. You'll notice the package no longer has a jre folder bundled inside it.

This specific package depends on ca-certificates-java which is purged in our setup due to old java versions

Can you explain what this means? Why is it purged and unable to be installed?

Which distro is this?

If you have some unusual setup and want to bring your own JRE you can presumably install the deb directly with dpkg and tell it to ignore the dependency?

We could also consider moving to optional/recommended/weak dependencies but I'm not really seeing the use case here just yet, would like to understand more whether there is a strong reason to avoid this 'clash'.

[david-m-m]

Hi,

one possible solution could be to depend on java17-runtime-headless (virtual package) which is provided by openjdk-17-jre-headless as well as temurin-17-jre (and probably others).

[chadlwilson]

I'm working on converting them to weak/recommended dependencies.

We considered depending on the virtual packages but they seemed to consider a higher version number as compatible whereas i want it to be strict as it takes time to validate GoCD against new Java LTS releases and some repos have non-LTS releases (e.g Temurin) which GoCD is strictly not validated against.

However thinking again, maybe we can express that with a specific constraint on the virtual packages (i.e =17 if we don't want 21 to be used?)

If you know more about deb packaging than me ideas are welcome. I'll link a PR soon for changing to recommended which is easier to opt out of without dpkg hijinx in any case.

[chadlwilson]

Debian also does not seem to have the 'alternatives' stuff that rpms do - which makes it easy to find the installed location of the JVM which we need to find to configure GoCD correctly - hopefully using relatively simple scripting.

[david-m-m]

I'm working on converting them to weak/recommended dependencies.

Not sure if this is the best way. After all java is required...

We considered depending on the virtual packages but they seemed to consider a higher version number as compatible whereas i want it to be strict as it takes time to validate GoCD against new Java KTS releases and some repos have non-LTS releases (e.g Temurin) which GoCD is strictly not validated against.

However thinking again, maybe we can express that with a specific constraint on the virtual packages (i.e =17 if we don't want 21 to be used?)

Indeed versioning of the virtual packages is somewhat problematic. To be precise: There is no explicit versioning, just the package name.

However in this case it should work as java17-runtime-headless already specifies the (major) version. Higher java versions like java 21 should not provide this virtual package though.

If you know more about deb packaging than me ideas are welcome.

Wouldn't rely on this although I'm tinkering occasionally with this for a few years. :-D

[david-m-m]

Debian also does not seem to have the 'alternatives' stuff that rpms do - which makes it easy to find the installed location of the JVM which we need to find to configure GoCD correctly - hopefully using relatively simple scripting.

Debian actually has an alternatives system. E.g. looks like this on my system:

user@localhost:~$ which java
/usr/bin/java
user@localhost:~$ ls -l /usr/bin/java
lrwxrwxrwx 1 root root 22  4. Nov 2021  /usr/bin/java -> /etc/alternatives/java
user@localhost:~$ ls -l /etc/alternatives/java
lrwxrwxrwx 1 root root 43 22. Jun 2023  /etc/alternatives/java -> /usr/lib/jvm/java-17-openjdk-amd64/bin/java
user@localhost:~$ ls -l /usr/lib/jvm/java-17-openjdk-amd64/bin/java
-rwxr-xr-x 1 root root 14392 22. Apr 12:26 /usr/lib/jvm/java-17-openjdk-amd64/bin/java

More information: https://wiki.debian.org/DebianAlternatives

As far as I understand, it works similar to the RPM system (which seems to be a fork/rewrite of the deb system).

[chadlwilson]

Yeah sorry, I should have articulated better. What I meant was that the alternatives system doesn’t create symlinks like jre_17 which allow you to have different JRE versions installed while keeping symlinks to your preferred variant for that “major version”. It seems to just keep links to a single “Java”. On RH based systems it’s got lots of symlink variants which makes it easy to target a specific LTS version without being opinionated about vendor.

[david-m-m]

Yeah sorry, I should have articulated better. What I meant was that the alternatives system doesn’t create symlinks like jre_17 which allow you to have different JRE versions installed while keeping symlinks to your preferred variant for that “major version”. It seems to just keep links to a single “Java”. On RH based systems it’s got lots of symlink variants which makes it easy to target a specific LTS version without being opinionated about vendor.

Thanks for the clarification. Actually the Debian alternatives system supports this. Unfortunately the openjdk package does not provide an appropriate config for the alternatives system.

[chadlwilson]

Hmm, it doesn't seem to matter too much, as even on RH-like distros, for example, the Temurin RPMs satisfy the virtual packages java-17-headless etc but don't actually register/update with the alternatives system, so can't rely on that to locate the install location of the preferred JRE 17 there either.

I'm working on converting them to weak/recommended dependencies.

Not sure if this is the best way. After all java is required...

I guess so, however it depends on whether users can reasonably expect to use a JRE tarballed and installed outside the package system; without having to dig into dpkg to ignore certain dependencies. In that sense, I guess a Java package install is recommended, but not absolutely required if you bring your own 😅

I am OK following up #12792 by adding a hard dependency to a virtual package with something like this untested hackish thing)

• if its not a reasonable expectation to use "recommends" like the above.
• if constraints can be specified on the virtuals for Debian (RH doesn't have this problem)
• if we can find a way to determine the bin/java location from any dependency that is satisfying the dependency. If a dependency is satisfying what GoCD is saying it needs, it seems reasonable for GoCD to be expected to know how to configure itself to use it. That seems to be the hard bit; there's seems no nice way to do this across both deb and rpm as locating the installation and using a path that is not specific-version dependent seems painful.

However in this case it should work as java17-runtime-headless already specifies the (major) version. Higher java versions like java 21 should not provide this virtual package though.

It works the way you describe on RH, but not for the standard Debian virtuals:

With Adoptium and standard repos:

root@b97d64d1fcd0:/# apt-get install java11-runtime-headless
Package java11-runtime-headless is a virtual package provided by:
  temurin-22-jre 22.0.1.0.0+8-1
  temurin-22-jdk 22.0.1.0.0+8-1
  temurin-21-jre 21.0.3.0.0+9-1
  temurin-21-jdk 21.0.3.0.0+9-1
  temurin-17-jre 17.0.11.0.0+9
  temurin-17-jdk 17.0.11.0.0+9
  temurin-11-jre 11.0.23.0.0+9
  temurin-11-jdk 11.0.23.0.0+9
  temurin-20-jre 20.0.2.0.0+9
  temurin-20-jdk 20.0.2.0.0+9
  temurin-19-jre 19.0.2.0.0+7-1
  temurin-19-jdk 19.0.2.0.0+7
  temurin-18-jdk 18.0.2.1+1
  openjdk-17-jre-headless 17.0.11+9-1~deb11u1
  openjdk-11-jre-headless 11.0.23+9-1~deb11u1
  default-jre-headless 2:1.11-72
You should explicitly select one to install.

You can similarly see this at https://debian.pkgs.org/11/debian-main-amd64/openjdk-11-jre-headless_11.0.22+7-1~deb11u1_amd64.deb.html

[chadlwilson]

Hmm, it doesn't seem to matter too much, as even on RH-like distros, for example, the Temurin
It works the way you describe on RH, but not for the standard Debian virtuals:

You can similarly see this at https://debian.pkgs.org/11/debian-main-amd64/openjdk-11-jre-headless_11.0.22+7-1~deb11u1_amd64.deb.html

Despite what this looks like, if openjdk-17-jre-headless is already installed, and I try to install a test package that

• has a hard requires dependency on java11-runtime-headless | java8-runtime-headless and
• recommends openjdk-11-jre-headless | openjdk-8-jre-headless

... it doesn't seem to consider openjdk-17-jre-headless as satisfying the dependency, despite openjdk-17-jre-headless 17.0.11+9-1~deb11u1 claiming it provides java11-runtime-headless.

I am confused! :-)

[chadlwilson]

Hi @tewfik-ghariani - do you have any opinion/preference on what would be the desirable state here? Is an optional dep you can --no-install-recommends good enough?

[tewfik-ghariani]

Hi @chadlwilson, yes I believe changing the dependency from forced to optional is a reasonable approach ^^