Reintroducing openjdk-8 for Bullseye?

[Andreas Beckmann]

On 06/05/2020 23.19, Moritz Mühlenhoff wrote:
> In any case reintroducing openjdk-8 as a generic package is not an
> option

Completely understandable.

> What is the JRE used for? I suppose it provides Java language bindings
> to access the CUDA libs?

No. nvidia-cuda-toolkit comes with two Eclipse-based applications:
nvidia-nsight (an IDE with CUDA support) and nvidia-visual-profiler (a
graphical profiler for CUDA applications on GPUs). Both are based on an
ancient version of Eclipse working only with ancient openjdk-8 and
contain some proprietary extensions built for that ancient Eclipse
version. Replacing (parts of) that copy of Eclipse with the version in
Debian did not work some years ago (#660908), and Eclipse is gone since
buster anyway.

There were rumors that nvidia was going to drop nvidia-visual-profiler,
but that has not yet happened for CUDA 11 (not yet packaged).

Their new tools nsight-systems and nsight-compute are Qt-based and don't
make that mess better. Instead of ancient java they require us to ship a
lot of older Qt libraries provided by Nvidia, because they are not
binary compatible with the newer versions in Debian (and we cannot
recompile their applications due to lack of source).

> Possible options which come to my mind:
> 
> - If only some users need the JRE, simply document where users can download
> it from adoptopenjdk.net (or even Oracle, after all CUDA is already non-free
> anyway). After all, that's what upstream chose to support as well.

While I would ditch nvidia-nsight (not sure if it even has a userbase),
I consider nvidia-visual-profiler (as long as it is shipped upstream) as
important for CUDA development s.t. it should work out-of-the-box.

> - Switch CUDA to multi tarball source package which includes the CUDA
> tarball plus the last version of OpenJDK 8. non-free isn't covered by
> security support anyway and for language bindings it shouldn't even
> ne strictly needed to follow the upstream releases (I guess Nvidia
> didn't either when they still bundled it?)

We already have multiple source^Wblob tarballs (one per arch: amd64,
ppc64el) and I had already tried to extract the ancient bundled amd64
JRE from 10.1U1 (in sid) to use it for 10.1U2 (in experimental, no
longer ships the JRE), which was quite easy (to be found on some git
branch). Building openjdk-8 from source would probably be an option,
too, but for now (10.1U2 at least) I'd like to stick with the really
ancient, but working binaries.


Andreas