Re: openjdk-8 vs. nvidia-openjdk-8-jre
Moritz Muehlenhoff dixit: >No, we have enough OpenJDK releases to look after already. OK, it was just a thought. Thanks, //mirabilos -- [00:02] gecko: benutzt du emacs ? [00:03] nö [00:03] nur n normalen mac [00:04] argl [00:04] ne den editor -- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)
Re: openjdk-8 vs. nvidia-openjdk-8-jre
On Fri, Jan 19, 2024 at 02:38:32AM +, Thorsten Glaser wrote: > Hi > > TIL about the existence of nvidia-openjdk-8-jre. > > Would it not be better to drop that and remove the bug deliberately > blocking openjdk-8 from entering testing/stable? No, we have enough OpenJDK releases to look after already. nvidia-openjdk-8-jre is on non-free (bundled with cuda) and not covered by security support. Cheers, Moritz
Re: openjdk-8 vs. nvidia-openjdk-8-jre
On Fri, Jan 19, 2024 at 11:43:11AM +0100, Andreas Beckmann wrote: >... > And having openjdk-8-* installed manually should not satisfy the openjdk > (build) dependency of any package in the archive via virtual packages. We already have two OpenJDK version (17 and 21) in bookworm. Everything should be fine if: - default-jre* is always the first alternative in the dependencies, and - everything requiring > 8 depends on a java*-runtime* >= java9-runtime* I'm not expecting these things to be 100% bug-free, but such things would already blow up today when someone still has a JRE from an older release installed (e.g. I was for some time using the security-supported openjdk-8/stretch on buster for a usecase where OpenJDK 11 did not work). > Andreas cu Adrian
Re: openjdk-8 vs. nvidia-openjdk-8-jre
Thomas, if I understand correctly, openjdk-8 is only needed for ancient
third-party software, not for anything in the Debian (main) archive.
But as such software still has a significant userbase, openjdk-8 ist
still being maintained by you and others and in other distributions.
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
openjdk-8 vs. nvidia-openjdk-8-jre
Hi,
TIL about the existence of nvidia-openjdk-8-jre.
Would it not be better to drop that and remove the bug deliberately
blocking openjdk-8 from entering testing/stable? We only added it so
there does not have to be formal security support for more than one
release.
And I’ve been building openjdk-8 for buster/bullseye/bookworm for a
while already, privately (for i386 and amd64), anyway, as people are
still using it, and *buntu also ships it and updates it in all LTS
releases. Freexian ELTS is also supporting it in jessie and stretch,
for the architectures these support.
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.
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.
bye,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
