[PR PATCH] [RFC] Fix alternatives for openjdk{11,17}

[PR PATCH] [RFC] Fix alternatives for openjdk{11,17}

[tornaria]

[-- Attachment #1: Type: text/plain, Size: 2888 bytes --]

There is a new pull request by tornaria against master on the void-packages repository

https://github.com/tornaria/void-packages jdk-alternatives
https://github.com/void-linux/void-packages/pull/47416

[RFC] Fix alternatives for openjdk{11,17}
<!-- Uncomment relevant sections and delete options which are not applicable -->

#### Testing the changes
- I tested the changes in this PR: **briefly**

Make sure alternatives for openjdk match the files that are shipped, to fix an issue with disappearing `/usr/bin/java`.

Steps to reproduce:
 - install `openjdk11-jre` so there is a symlink `/usr/bin/java -> ../lib/jvm/openjdk11/bin/java`
 - install `openjdk11` so the alternative switches from `java` to `jdk`, which also makes a symlink `/usr/bin/java -> ../lib/jvm/openjdk11/bin/java`
 - uninstall `openjdk11` so the alternative switches back from `jdk` to `java`. The symlink will be removed for `jdk` but not added back for `java`.

Arguably this is a bug in `xbps-alternatives`, but it doesn't seem ok for a package to provide an alternative for a file it doesn't contain (or for two packages to provide the exact same alternative.

However, I'm not sure this is ok. What happens if one tries to use `jdk` alternative from one version and `java` alternative from a different version? Maybe that's the reason why this was set up this way. Thus the [RFC]. I also didn't bump the revision, let me know if I should do that or just fix it and wait for a next update.

I found this while installing and uninstalling `jmol` which depends on `java-environment`, thus `openjdk11` would be installed/uninstalled breaking `/bin/java` for me. I also think `jmol` should not depend on java-environment but that java-runtime should be good enough (it seems to run ok; I don't use it directly but only through sage which uses it sometimes to create png files). So I added a commit here to that effect, but of course I could move that to a separate PR.

Ping: @mhmdanas @classabbyamp since you often update these.

<!--
#### New package
- This new package conforms to the [package requirements](https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#package-requirements): **YES**|**NO**
-->

<!-- Note: If the build is likely to take more than 2 hours, please add ci skip tag as described in
https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#continuous-integration
and test at least one native build and, if supported, at least one cross build.
Ignore this section if this PR is not skipping CI.
-->
<!--
#### Local build testing
- I built this PR locally for my native architecture, (ARCH-LIBC)
- I built this PR locally for these architectures (if supported. mark crossbuilds):
  - aarch64-musl
  - armv7l
  - armv6l-musl
-->


A patch file from https://github.com/void-linux/void-packages/pull/47416.patch is attached

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: github-pr-jdk-alternatives-47416.patch --]
[-- Type: text/x-diff, Size: 4160 bytes --]

From 4b3d130bba421453247b7191bbc9b28b6f4afed7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gonzalo=20Tornar=C3=ADa?= <tornaria@cmat.edu.uy>
Date: Sun, 26 Nov 2023 12:16:49 -0300
Subject: [PATCH 1/3] openjdk11: fix alternatives

---
 srcpkgs/openjdk11/template | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/srcpkgs/openjdk11/template b/srcpkgs/openjdk11/template
index b5dd94241a0c8..f8df2a88ac782 100644
--- a/srcpkgs/openjdk11/template
+++ b/srcpkgs/openjdk11/template
@@ -77,7 +77,6 @@ alternatives="
  jdk:/usr/bin/jaotc:/${_jdk_home}/bin/jaotc
  jdk:/usr/bin/jar:/${_jdk_home}/bin/jar
  jdk:/usr/bin/jarsigner:/${_jdk_home}/bin/jarsigner
- jdk:/usr/bin/java:/${_jdk_home}/bin/java
  jdk:/usr/bin/javac:/${_jdk_home}/bin/javac
  jdk:/usr/bin/javadoc:/${_jdk_home}/bin/javadoc
  jdk:/usr/bin/javap:/${_jdk_home}/bin/javap
@@ -86,10 +85,10 @@ alternatives="
  jdk:/usr/bin/jdb:/${_jdk_home}/bin/jdb
  jdk:/usr/bin/jdeprscan:/${_jdk_home}/bin/jdeprscan
  jdk:/usr/bin/jdeps:/${_jdk_home}/bin/jdeps
+ jdk:/usr/bin/jfr:/${_jdk_home}/bin/jfr
  jdk:/usr/bin/jhsdb:/${_jdk_home}/bin/jhsdb
  jdk:/usr/bin/jimage:/${_jdk_home}/bin/jimage
  jdk:/usr/bin/jinfo:/${_jdk_home}/bin/jinfo
- jdk:/usr/bin/jjs:/${_jdk_home}/bin/jjs
  jdk:/usr/bin/jlink:/${_jdk_home}/bin/jlink
  jdk:/usr/bin/jmap:/${_jdk_home}/bin/jmap
  jdk:/usr/bin/jmod:/${_jdk_home}/bin/jmod
@@ -99,13 +98,8 @@ alternatives="
  jdk:/usr/bin/jstack:/${_jdk_home}/bin/jstack
  jdk:/usr/bin/jstat:/${_jdk_home}/bin/jstat
  jdk:/usr/bin/jstatd:/${_jdk_home}/bin/jstatd
- jdk:/usr/bin/keytool:/${_jdk_home}/bin/keytool
- jdk:/usr/bin/pack200:/${_jdk_home}/bin/pack200
  jdk:/usr/bin/rmic:/${_jdk_home}/bin/rmic
- jdk:/usr/bin/rmid:/${_jdk_home}/bin/rmid
- jdk:/usr/bin/rmiregistry:/${_jdk_home}/bin/rmiregistry
  jdk:/usr/bin/serialver:/${_jdk_home}/bin/serialver
- jdk:/usr/bin/unpack200:/${_jdk_home}/bin/unpack200
 "
 
 post_extract() {

From e5bb43a0668319493448be8cc1522b69a9ec8274 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gonzalo=20Tornar=C3=ADa?= <tornaria@cmat.edu.uy>
Date: Sun, 26 Nov 2023 12:16:54 -0300
Subject: [PATCH 2/3] openjdk17: fix alternatives

---
 srcpkgs/openjdk17/template | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/srcpkgs/openjdk17/template b/srcpkgs/openjdk17/template
index bb72701f360e6..4c2d46db656a4 100644
--- a/srcpkgs/openjdk17/template
+++ b/srcpkgs/openjdk17/template
@@ -86,7 +86,6 @@ fi
 alternatives="
  jdk:/usr/bin/jar:/${_jdk_home}/bin/jar
  jdk:/usr/bin/jarsigner:/${_jdk_home}/bin/jarsigner
- jdk:/usr/bin/java:/${_jdk_home}/bin/java
  jdk:/usr/bin/javac:/${_jdk_home}/bin/javac
  jdk:/usr/bin/javadoc:/${_jdk_home}/bin/javadoc
  jdk:/usr/bin/javap:/${_jdk_home}/bin/javap
@@ -95,7 +94,6 @@ alternatives="
  jdk:/usr/bin/jdb:/${_jdk_home}/bin/jdb
  jdk:/usr/bin/jdeprscan:/${_jdk_home}/bin/jdeprscan
  jdk:/usr/bin/jdeps:/${_jdk_home}/bin/jdeps
- jdk:/usr/bin/jfr:/${_jdk_home}/bin/jfr
  jdk:/usr/bin/jhsdb:/${_jdk_home}/bin/jhsdb
  jdk:/usr/bin/jimage:/${_jdk_home}/bin/jimage
  jdk:/usr/bin/jinfo:/${_jdk_home}/bin/jinfo
@@ -109,8 +107,6 @@ alternatives="
  jdk:/usr/bin/jstack:/${_jdk_home}/bin/jstack
  jdk:/usr/bin/jstat:/${_jdk_home}/bin/jstat
  jdk:/usr/bin/jstatd:/${_jdk_home}/bin/jstatd
- jdk:/usr/bin/keytool:/${_jdk_home}/bin/keytool
- jdk:/usr/bin/rmiregistry:/${_jdk_home}/bin/rmiregistry
  jdk:/usr/bin/serialver:/${_jdk_home}/bin/serialver
 "
 

From 0db66ce05b6a0a9d8e241755bb5343f956aa573b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gonzalo=20Tornar=C3=ADa?= <tornaria@cmat.edu.uy>
Date: Sun, 26 Nov 2023 12:17:21 -0300
Subject: [PATCH 3/3] jmol: depend on java-runtime instead of java-environment

---
 srcpkgs/jmol/template | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/srcpkgs/jmol/template b/srcpkgs/jmol/template
index 7217fdfaeb90d..4a61160eb454a 100644
--- a/srcpkgs/jmol/template
+++ b/srcpkgs/jmol/template
@@ -2,7 +2,7 @@
 pkgname=jmol
 version=16.1.9
 revision=1
-depends="virtual?java-environment"
+depends="virtual?java-runtime"
 short_desc="Open-source Java/JavaScript-based molecule viewer"
 maintainer="Brenton Horne <brentonhorne77@gmail.com>"
 license="LGPL-2.1-or-later"

Re: [RFC] Fix alternatives for openjdk{11,17}

[ahesford]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/pull/47416#issuecomment-1827699228

Comment:
If the jdk/java selections must be consistent (it seems like they ought to be), I wonder if the better approach is to move everything to a common `Java` alternative. The JRE packages could provide a subset of the full alternative group provided by the JDK packages. Whether the alternatives system behaves properly here requires testing.

Re: [RFC] Fix alternatives for openjdk{11,17}

[classabbyamp]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/pull/47416#issuecomment-1828067651

Comment:
yeah it's fairly complex. it's trying to make it so the jdk and jre groups match by making the former a superset of the latter. this has existed longer than I've been around so I don't know what's up really. there's probably a better way. 

Re: [RFC] Fix alternatives for openjdk{11,17}

[tornaria]

[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]

New comment by tornaria on void-packages repository

https://github.com/void-linux/void-packages/pull/47416#issuecomment-1828939711

Comment:
> yeah it's fairly complex. it's trying to make it so the jdk and jre groups match by making the former a superset of the latter. this has existed longer than I've been around so I don't know what's up really. there's probably a better way.

I see, but the problem is that `xbps-alternatives` doesn't handle duplicate alternatives gracefully...

In the comment above I showed steps to reproduce a bad behavior in this respect. What is the bad behavior that would be caused by "fixing" the alternatives as I suggest in this PR?

> If the jdk/java selections must be consistent (it seems like they ought to be), I wonder if the better approach is to move everything to a common `Java` alternative. The JRE packages could provide a subset of the full alternative group provided by the JDK packages. Whether the alternatives system behaves properly here requires testing.

So we would have (say) four providers for the `java` alternative group:
 - openjdk11-jre
 - openjdk11
 - openjdk17-jre
 - openjdk17

But then, say I choose `openjdk11-jre` alternative, and later I install `openjdk11` then I won't have the symlinks for the binaries in `openjdk11`.

Re: [RFC] Fix alternatives for openjdk{11,17}

[classabbyamp]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/pull/47416#issuecomment-1829943383

Comment:
basically what needs to happen is:
- if only 1 JRE is installed, it should be `java` and the same for the other JRE programs
- if only 1 JDK is installed, same thing for the JDK tools
- if multiple JREs or JDKs are installed, then the `java` and JDK tools must be the same version.

but because each version is split in 2 packages, it's hard to do.

I think it may be possible to do this with a script (multicall, so it can act as any of the tools) that gets installed in /usr/bin.

Perhaps the alternative group could manage a symlink like `/usr/lib/jvm/openjdk-jre -> /usr/lib/jvm/openjdk##` and `/usr/lib/jvm/openjdk-jdk -> /usr/lib/jvm/openjdk##`, and the script wrapper ensures they're the same version.

```sh
#!/bin/sh

prog="$0"

if [ -e "/usr/lib/jvm/openjdk-jdk" ]; then
    if [ "$(realpath /usr/lib/jvm/openjdk-jdk)" != "$(realpath /usr/lib/jvm/openjdk-jre)" ]; then
        echo "WARNING! JDK/JRE mismatch! use xbps-alternatives to choose one"
    fi
    exec "/usr/lib/jvm/openjdk-jdk/bin/$prog" "$@"
fi

exec "/usr/lib/jvm/openjdk-jre/bin/$prog" "$@"
```
(just spitballing here)

Re: [RFC] Fix alternatives for openjdk{11,17}

[classabbyamp]

[-- Attachment #1: Type: text/plain, Size: 179 bytes --]

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/pull/47416#issuecomment-1829965494

Comment:
also don't forget about openjdk8

Re: [RFC] Fix alternatives for openjdk{11,17}

[ahesford]

[-- Attachment #1: Type: text/plain, Size: 273 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/pull/47416#issuecomment-1830470211

Comment:
I think wrapping the Java commands in a script that monitors a pair of alternative links is the best approach we'll get with XBPS.

Re: [RFC] Fix alternatives for openjdk{11,17}

[classabbyamp]

[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/pull/47416#issuecomment-1829943383

Comment:
basically what needs to happen is:
- if only 1 JRE is installed, it should be `java` and the same for the other JRE programs
- if only 1 JDK is installed, same thing for the JDK tools
- if multiple JREs or JDKs are installed, then the `java` and JDK tools must be the same version.

but because each version is split in 2 packages, it's hard to do.

I think it may be possible to do this with a script (multicall, so it can act as any of the tools) that gets installed in /usr/bin.

Perhaps the alternative group could manage a symlink like `/usr/lib/jvm/openjdk-jre -> /usr/lib/jvm/openjdk##` and `/usr/lib/jvm/openjdk-jdk -> /usr/lib/jvm/openjdk##`, and the script wrapper ensures they're the same version.

```sh
#!/bin/sh

prog="$(basename "$0")"

if [ -e "/usr/lib/jvm/openjdk-jdk" ]; then
    if [ "$(realpath /usr/lib/jvm/openjdk-jdk)" != "$(realpath /usr/lib/jvm/openjdk-jre)" ]; then
        echo "WARNING! JDK/JRE mismatch! use xbps-alternatives to choose one"
    fi
    exec "/usr/lib/jvm/openjdk-jdk/bin/$prog" "$@"
fi

exec "/usr/lib/jvm/openjdk-jre/bin/$prog" "$@"
```
(just spitballing here)

Re: [RFC] Fix alternatives for openjdk{11,17}

[tornaria]

[-- Attachment #1: Type: text/plain, Size: 170 bytes --]

New comment by tornaria on void-packages repository

https://github.com/void-linux/void-packages/pull/47416#issuecomment-1868148627

Comment:
Closing in favor of #47866 

Re: [PR PATCH] [Closed]: [RFC] Fix alternatives for openjdk{11,17}

[tornaria]

[-- Attachment #1: Type: text/plain, Size: 2726 bytes --]

There's a closed pull request on the void-packages repository

[RFC] Fix alternatives for openjdk{11,17}
https://github.com/void-linux/void-packages/pull/47416

Description:
<!-- Uncomment relevant sections and delete options which are not applicable -->

#### Testing the changes
- I tested the changes in this PR: **briefly**

Make sure alternatives for openjdk match the files that are shipped, to fix an issue with disappearing `/usr/bin/java`.

Steps to reproduce:
 - install `openjdk11-jre` so there is a symlink `/usr/bin/java -> ../lib/jvm/openjdk11/bin/java`
 - install `openjdk11` so the alternative switches from `java` to `jdk`, which also makes a symlink `/usr/bin/java -> ../lib/jvm/openjdk11/bin/java`
 - uninstall `openjdk11` so the alternative switches back from `jdk` to `java`. The symlink will be removed for `jdk` but not added back for `java`.

Arguably this is a bug in `xbps-alternatives`, but it doesn't seem ok for a package to provide an alternative for a file it doesn't contain (or for two packages to provide the exact same alternative.

However, I'm not sure this is ok. What happens if one tries to use `jdk` alternative from one version and `java` alternative from a different version? Maybe that's the reason why this was set up this way. Thus the [RFC]. I also didn't bump the revision, let me know if I should do that or just fix it and wait for a next update.

I found this while installing and uninstalling `jmol` which depends on `java-environment`, thus `openjdk11` would be installed/uninstalled breaking `/bin/java` for me. I also think `jmol` should not depend on java-environment but that java-runtime should be good enough (it seems to run ok; I don't use it directly but only through sage which uses it sometimes to create png files). So I added a commit here to that effect, but of course I could move that to a separate PR.

Ping: @mhmdanas @classabbyamp since you often update these.

<!--
#### New package
- This new package conforms to the [package requirements](https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#package-requirements): **YES**|**NO**
-->

<!-- Note: If the build is likely to take more than 2 hours, please add ci skip tag as described in
https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#continuous-integration
and test at least one native build and, if supported, at least one cross build.
Ignore this section if this PR is not skipping CI.
-->
<!--
#### Local build testing
- I built this PR locally for my native architecture, (ARCH-LIBC)
- I built this PR locally for these architectures (if supported. mark crossbuilds):
  - aarch64-musl
  - armv7l
  - armv6l-musl
-->