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`.