Re: OpenJDK 17 for bullseye-backports
[please ignore this thread started by Adrian; he's making statements on behalf of other teams, which are not correct. Also he "forgot" to CC the security team and the package maintainers. The issue is handled in #975016.] On 2/6/21 11:47 PM, Emmanuel Bourg wrote: > Le 02/02/2021 à 19:04, Adrian Bunk a écrit : > I agree that shipping a non LTS release of OpenJDK (12 to 16) is a bad > idea. Shipping OpenJDK 17 is worth considering though. > > >> 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. > > If openjdk-17 can't be shipped in bullseyes even with prominent warnings > that it's unsupported, then this sounds like a good idea. See #975016. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975016#98 lists the proposals made. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975016#123 lists the OK of the security team for all proposals. So I'm going with option 1, preparing for an openjdk-17 in bullseye, and preparing release notes and notes for security support. This is more conservative than option 2, but allows to do better than the commitment made. The option also has the advantage that approval is only needed by the security team. openjdk-17 already is in testing. granting unblock requests for new snapshot builds by the release team would be appreciated, but isn't strictly necessary as long as we can build newer snapshots. And that can be checked in unstable. Matthias
Re: OpenJDK 17 for bullseye-backports
Le 07/02/2021 à 00:43, Thorsten Glaser a écrit : > Users will probably ignore that and use it anyway. It would have been > good if it could be included and kept up to date, but that’s doubling > of efforts, not worth the hassle, I wonder if the effort of maintaining OpenJDK 17 in bullseyes could be significantly reduced by automating the process. The upstream LTS branch is going to be extremely stable, the releases are clearly tagged in the upstream repository, and the Debian packaging is very flexible and compatible with several Debian releases. It should be possible to fetch the upstream security updates, rebase the Debian packaging and upload the package automatically. That wasn't possible a few years ago, I vaguely remember Matthias telling me that up to Java 8 the security updates were not easily identifiable in the upstream repository (if available at all), and that some architectures required changes cherry picked from alternative repositories. If we can't rely on the main upstream repository to support all the Debian architectures, maybe we can restrict the automatic updates to those supported upstream (at least amd64 and i386, maybe arm64 too). > plus it would mean people would expect Java packages shipped with bullseye > to work with 17, which isn’t the case (plus shipping only one makes > iteasier/clearer). The compatibility of the Java packages in bullseye with OpenJDK 17 is rather good. I ran a mass rebuild this week and the success rate was around 85%. There were many trivial build issues (javadoc errors, language level to change from 6 to 7) so the runtime compatibility is likely to be higher. I've filed the issues in the BTS: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=default-java17;users=debian-j...@lists.debian.org Emmanuel Bourg
Re: OpenJDK 17 for bullseye-backports
On Sat, 6 Feb 2021, Emmanuel Bourg wrote:
> If openjdk-17 can't be shipped in bullseyes even with prominent warnings
> that it's unsupported
Users will probably ignore that and use it anyway. It would have been
good if it could be included and kept up to date, but that’s doubling
of efforts, not worth the hassle, plus it would mean people would ex‐
pect Java packages shipped with bullseye to work with 17, which isn’t
the case (plus shipping only one makes it easier/clearer).
>, then this sounds like a good idea.
FWIW there is some discussion around this near
https://lists.debian.org/debian-java/2020/11/threads.html#00025
and we sincerely hope that a one-time copying of the binary packages
from sid to bullseye-backports, followed by either binNMUing or a
regular upload, can be done.
The situation is currently like this:
$ rmadison openjdk-1{1,2,3,4,5,6,7,8}
openjdk-11 | 11.0.4+11-1~bpo9+1 | stretch-backports | source
openjdk-11 | 11.0.4+11-1~deb10u1 | stable| source
openjdk-11 | 11.0.4+11-1 | unstable | source
openjdk-11 | 11.0.6+10-1~bpo9+1 | stretch-backports | source
openjdk-11 | 11.0.9.1+1-1~deb10u2 | stable| source
openjdk-11 | 11.0.10+9-1 | testing | source
openjdk-11 | 11.0.10+9-1 | unstable | source
openjdk-15 | 15.0.2+7-1 | unstable | source
openjdk-16 | 16~34-1 | testing | source
openjdk-16 | 16~35-1 | buildd-unstable | source
openjdk-16 | 16~35-1 | unstable | source
openjdk-17 | 17~7-1 | testing | source
openjdk-17 | 17~8-1 | buildd-unstable | source
openjdk-17 | 17~8-1 | unstable | source
The idea here is to drop all but openjdk-11 from testing (→ bullseye)
while waiting for the official release of 17 in sid and backporting
that one it has migrated to testing/bookworm.
Adrian’s suggestion to use bpo version numbers in sid for this…
>>Slightly less bending of the rules and only marginally more effort would
>>be to build ~bpo11+1 binaries for all bullseye release architectures
>>in unstable before the release of bullseye.
… sounds interesting, this keeps users’ expectations for backports
and is easily fixed in sid by uploading, once the copying is done.
(And, if needed, doing a ~bpo11+1b1 or ~bpo11+2 in backports.)
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
*
Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.
Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.
*
Re: OpenJDK 17 for bullseye-backports
Le 02/02/2021 à 19:04, Adrian Bunk a écrit :
> 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.
I did that to backport openjdk-11 to stretch and that was indeed
tedious. It consisted in uploading openjdk-{9,10,11} to
stretch-backports, not as separate packages but sequentially as the
final openjdk-11 package. At each step I had to wait for the builders to
complete the build before uploading the next version. And it took a lot
of time on some architectures (especially mipsel if I remember well, the
backport queue is processed with a lower priority and the builder is
constantly used for higher priority builds).
The whole backport was completed in 2 weeks. I guess a similar process
to bootstrap openjdk-17 from openjdk-11 would take 1 month.
> 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.
I agree that shipping a non LTS release of OpenJDK (12 to 16) is a bad
idea. Shipping OpenJDK 17 is worth considering though.
> 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.
If openjdk-17 can't be shipped in bullseyes even with prominent warnings
that it's unsupported, then this sounds like a good idea.
Emmanuel Bourg
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
