Keep this package in unstable (and possibly experimental) for now.
It is to be used officially only for bootstrapping JVM-based languages
like Kotlin, as well as to provide LTS packages for stretch and ELTS
for jessie.

Users may use this further at their own risk, with no support.
I’m providing precompiled backports for all Debian releases from wheezy
onwards and all *buntu LTS releases from precise (12.04) onwards in my
personal APT repository; contact me, or see extrepo-data, for details.

close 1066051
thanks

Fab Stz dixit:

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.

Yes, this is to be expected.

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.

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.

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.

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.

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

────────────────────────────────────────────────────────────────────────

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.

To my knowledge, the only one continuously updated and using “proper”
Debian packaging mechanisms etc.

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

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

 Thanks for the information.


     Le lundi 11 mars 2024 à 21:52:54 UTC+1, Thorsten Glaser <tg@mirbsd.de> a écrit :

 close 1066051
thanks

Fab Stz dixit:

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.

Yes, this is to be expected.

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.

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.

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.

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.

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

────────────────────────────────────────────────────────────────────────

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.

To my knowledge, the only one continuously updated and using “proper”
Debian packaging mechanisms etc.

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

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