On 19/01/2024 03.38, Thorsten Glaser wrote:
The other side would be nvidia-openjdk-8-jre is in non-free and only available for two architectures, so less people would install it, and it’s JRE-only, AFAICT. If worry about people installing openjdk-8 is a factor, I can understand the split, but from a technical PoV I don’t see the duplication as a good solution.
nvidia-visual-profiler (which is a customized ancient eclipse with some proprietary plugins) from src:nvidia-cuda-toolkit in non-free unfortunately still requires openjdk-8 (and I don't expect that to change before the visual-profiler gets dropped at some point by upstream (but I haven't heard any rumours about that, yet)).
nvidia-openjdk-8-jre is simply a repack of the openjdk-8-jre{,-headless} binary packages from sid (only for amd64 and ppc64el which have nvidia-visual-profiler, not for arm64 which got CUDA support w/o visual-profiler a few years later) and it would be trivial to drop that from src:nvidia-cuda-toolkit (we already do that on Ubuntu and use openjdk-8-jre there instead).
I'd be in favor of switching to official openjdk-8 packages in main, as it would simplify my nvidia-cuda-toolkit work ;-) And openjdk-8 in sid seems to be still well maintained today (it didn't look that way a few years ago).
Options are probably: keep things as is, drop nvidia-openjdk-8-jre in
favour of openjdk-8 in trixie/sid, or drop it everywhere and build
openjdk-8 for {,{,old}old}stable as well. I don’t mind any, I just
wondered and wanted to provide an impulse to think about this.
If it's going to be reintroduced to (old)*stable/testing, we should ensure that no package in the archive accidentally pulls it in as part of its dependency resolution ... i.e. there are no leftover openjdk-8-* (build) dependency alternatives. And having openjdk-8-* installed manually should not satisfy the openjdk (build) dependency of any package in the archive via virtual packages.
Andreas