OpenJDK 17 for bullseye-backports
The problem:
OpenJDK 11 LTS is the default JDK in both buster and bullseye.
The next LTS OpenJDK 17 is already in unstable, but it will not even
have a stable release by the time bullseye releases.
OpenJDK 17 is expected to be the OpenJDK in bookworm.
Some users will want to use OpenJDK 17 on bullseye.
The security team is (understandably) strictly against security
supporting two OpenJDK versions in a stable release.
bullseye-backports would be the perfect place for providing
OpenJDK 17 to users on bullseye.
OpenJDK can only be built with the previous version, and doing a
11 -> 12 -> 13 -> 14 -> 15 -> 16 -> 17
bootstrap for 9 release architectures in bullseye-backports would be
quite painful.
Shipping without any security support either OpenJDK 16 or a pre-release
of OpenJDK 17 in bullseye only for avoiding an OpenJDK bootstrap in
bullseye-backports would sound very wrong.
My suggestion:
No OpenJDK other than 11 is shipped in bullseye.
If at the time of the bullseye release openjdk-17 in unstable is ready
to migrate to testing except for the freeze, this means that:
1. it will migrate at the first migration of bookworm, and
2. the binaries will be installable on all architectures in bullseye
The bootstrap could then be avoided by verbatim copying of this
openjdk-17 sources and binaries for all architectures from bookworm
to bullseye-backports.
Subsequent updates of openjdk-17 in bullseye-backports would then follow
the normal backports rules.
This suggestion requires:
1. that (temporarily) having the same version in bookworm+unstable and
bullseye-backports is not a problem for the archive or backports
software, and
2. willingness from the ftp team to do that, and
3. agreement from the backports team
cu
Adrian
Reply to: