On 24.05.19 20:29, Martijn Verburg wrote: > On Fri, 24 May 2019 at 15:40, tony mancill <tmanc...@debian.org> wrote: > >> On Thu, May 23, 2019 at 11:58:14PM +0200, Emmanuel Bourg wrote: >>> Le 23/05/2019 à 19:04, Martijn Verburg a écrit : >>> >>>> What was the difficulty in grabbing the 11.0.3+7 tag directly? >>> >>> The difficulty is the policy that applies to backported packages. A >>> package that is backported from the Debian release n+1 to the release n >>> has to remain upgradable when the system is upgraded. For this to happen >>> the version backported must rank lower than the version in the next >>> release. That's why there are weird suffixes appended to the versions of >>> the backported packages (1.2.3-1~bpo9+1 is lower than 1.2.3-1). >>> >>> Currently Debian Buster has openjdk-11/11.0.3+1-1, so it isn't possible >>> to upload the version 11.0.3+7-1~bpo9+1 to stretch-backports. The only >>> solutions is to either upgrade openjdk-11 in testing to a version higher >>> than 11.0.3+7, or patch the existing version. Since testing is currently >>> frozen and difficult to update until the release of Buster, it leaves >>> only the patch solution. >> >> Emmanuel, >> >> It seems like we need to bring this up with the Release and Security >> teams. Releasing Buster with mulitple critical open CVEs in the JVM >> isn't a good experience for our users. My proposal is that we do what >> we need to get 11.0.3-ga-1 into Buster. >> >> From a versioning standpoint, this should work. Am I missing something? >> >> $ dpkg --compare-versions 11.0.3-ga-1 gt 11.0.3+7-1 && echo "11.0.3-ga-1 >> is newer" >> 11.0.3-ga-1 is newer
I don't think that playing games with version numbers is a good thing to do. Version numbers should match the upstream source release, and the binary packages should not change that version. Of course openjdk has a split personality to give even another version when called with java --version The final 11.0.3 release: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000951.html does *not* contain the ea specifier. > We (AdoptOpenJDK) would really be appreciative of that! We're aiming to get > consistency amongst all of the OpenJDK providers that 'good known GA' > versions are deployed to end users. I can only apologise for not having > reached out to the Debian community earlier to collaborate. Appreciate the > efforts being put in here! I don't care what AdoptJdk is doing. In the past, the only activity by AdoptJdk was trying to promote their builds for inclusion in some Linux distros. AdoptJdk only supports a subset of the Debian architectures, and we really don't need yet another IcedTea. > Is there anything we can do to help going forward? OpenJDK upstream has a > pretty good established policy around having the `-ga` suffix added to > versions it would like downstream to take as a formal release. This is a recent addition. Last time I asked on an upstream mailing list, everybody seemed fine with the versioning: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000969.html > Is there > anything else that OpenJDK can do to help Debian? One thing that > AdoptOpenJDK provides is a free test pipeline in it's build farm that could > happily receive the Debian built binary and put it through 100,000+ tests > and see if it matches what other OpenJDK providers are broadly producing, > would that be of interest? I'm moving that discussion to upstream, but in summary you shouldn't a dozen of configure options to configure your build from source. Just release a sane upstream tarball. Matthias
