close 1066051 thanks Fab Stz dixit:
>I usually install openjdk-8 from unstable on bookworm. This has never been officially supported. I’ve had an entire discussion around that last month, which I will quote parts from below, for context. >However this is not possible anymore because now it depends on t64 packages. Yes, this is to be expected. >Would it be possible to still install it on systems without t64 by >updating the dependencies/build-depends? No. But (see the background information below) I’ll be making available openjdk-8 packages built for bookworm in the “wtf-lts” extrepo soon (with the next upload, which will be done once the t64 transition has settled, i.e. in some days) if you don’t mind an inofficial repo (though operated by the same person who uploads the package to Debian proper so…), although for amd64 and i386 only at the moment, as I lack hardware to build for other platforms (tell me if you need that). The RSS feed for the wtf extrepo will tell you when. You can obtain that at http://www.mirbsd.org/~tg/Debs/NEWS.rss (s/\.rss// for plaintext). Quotes, some paraphrased, follow. Cc’ing the relevant bug for archival and public readability. ──────────────────────────────────────────────────────────────────────── OpenJDK 8 is included with Debian 9 (stretch) only, although it has been retrofitted to Debian 8 (jessie) for ELTS as it still is actively maintained, in contrast to jessie’s OpenJDK 7. Debian 10 and 11 shipped OpenJDK 11, due to misalignment between Debian’s and OpenJDK-LTS’ release cycles. > (why does #989736 to keep OpenJDK out of testing and stable exist?) The reason behind it is that every Debian release contains exactly one, and only one, supported OpenJDK version; the security team does not have resources for more (unlike commercial distributions, nobody is paid for their work). OpenJDK 8 had already been dropped from Debian, but I’ve resurrected it and took over maintenance. We still use it in Debian proper for: • staging new releases for ELTS (ELTS is not part of Debian proper but an external offering, although basically done by the same people) • bootstrapping new environments (like Kotlin) that depend on JDK 8 for their bootstrapping process This is all done in “unstable”; Kotlin was only able to enter “testing” once it met the release goals for the “next-stable”, that is to build with that then-future release’s default JDK. > There are a number of applications still depending on Java 8. Most of these should still run with 11 at least, even if they can only be built on 8 or with special options (I wrote a Maven parent POM that manages this). I know of exceptions that use undocumented/inofficial interfaces that are not actually part of the JDK’s API. For these, it’s really SOL… I personally don’t have a problem with making OpenJDK 8 releases available for other Debian releases; this is in fact how my involvement in this started (I did it for a customer but also made the results publicly available). If you don’t mind external repositories, you can use the builds from there. I recently stopped making builds for Debian 7 (wheezy) even if that is technically still feasible, because it is no longer supported by even ELTS. Debian 8 and 9 are provided OpenJDK 8 by Freexian ELTS. I produce builds for Debian 10 and 11, amd64 and i386 only (I lack the machines to do more currently). I don’t provide these packages for Debian 12 because I do not use the latter and have no way to test them and can so save time. Given incentive (a nice offer) I might add more to this mix. I also provide OpenJDK 8 for all *buntu LTS releases that Canonical allows Launchpad to build for, for all architectures the respective releases have, via a PPA. > (would be convenient to add openjdk-8 to stable) Once a Debian stable is released, packages aren’t added to it any more, barring special cases in LTS/ELTS releases like the aforementioned switching jessie from OpenJDK 7 to 8, or they all getting newer kernels. > (does the bugreport mean it will forever be blocked from making it to stable?) Yes, it blocks OpenJDK 8 from ever reaching testing, and a new stable is made by copying a frozen testing at the point in time where the release gets made. This is, indeed, the purpose of that debbugs item. The “Outlook” and the first message should have made that clear. (The latter also said to contact me so all is fine.) This is the compromise that allowed OpenJDK 8 to be kept in Debian at all, i.e. in Debian unstable; otherwise the security team would have veto’d this. There is no way for OpenJDK 8 to be supported in a stable Debian release any more. That doesn’t mean I desupport this in the package itself. While I don’t build for or test on wheezy or precise any more, these two and anything newer, up to the latest respective releases, should work, and I occasionally do things to make it so. You just have to obtain them from elsewhere than Debian itself… or, of course, do the building yourself (there are a couple of files that do need changing to match the target distribution and release; there is an automated process for it which has to be manually triggered first though, as it regenerates metadata; and then you need a proper clean+minimal cowbuilder or sbuild/buildd environment to build the actual binary packages). ──────────────────────────────────────────────────────────────────────── (There’s also the Debian package extrepo which can automate the setup of the repository.) ──────────────────────────────────────────────────────────────────────── > (is it correct that this is your personal repo where you packaged this > for a customer but also made it publicly available?) Yes and no, it’s a bit more complicated than that. I did the whole backporting for a customer at $dayjob at first and used a different repo for the deliverables using the same tools I had already made to manage my personal repo already. At some point it was ok’d for me to also provide these packages to the public. Since a few years, that customer is no longer one due to changes imposed from elsewhere (they had a specific project with us which they had to get rid of to switch to Microsoft crap as mandated by another ministry), but I continue the openjdk-8 builds, partially on company time, as my employer used to be proud of doing FOSS things. And when openjdk-8 got dropped in Debian, I took over maintainership and undid the dropping. > And possibly this is currently the only publicly > available Debian repo that contains jdk-8 for Debian 11/12? To my knowledge, the only one continuously updated and using “proper” Debian packaging mechanisms etc. > What I did as a final step was pin your repo like this: > > /etc/apt/preferences.d/99my-custom-repository > Package: * > Pin: origin www.mirbsd.org > Pin-Priority: 1 > > Package: openjdk-8-* > Pin: origin www.mirbsd.org > Pin-Priority: 500 Right. The “lts” component already contains fewer packages than the “wtf” component in the same repo, only the packages I would also upload to Debian itself in the very same state (if that would be acceptable), but if you want only the JDK, that’s fine and less risky. The full list of packages included in the “lts” list is semi-stable (changes announced on the RSS) and documented on http://www.mirbsd.org/~tg/Debs/sources.txt/2-ltslst.txt as well. (On which I guess I’ll have to move bookworm to supported again, although I’ll rely on user testing at least for more than the tests I do during development.) > (the enquirer will help testing) Sounds great. I’m not currently in a Java project @ $dayjob, so my use (and testing every time) is rather minimal (a bit of Maven build+test, a bit of tomcat9 testing, and I use it to run a (oldish) Jenkins instance); my Debian ELTS contact person also does his own testing, although with the jessie/stretch builds of course (same source, built in different environment).