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-java@lists.debian.org Emmanuel Bourg
