Re: Debian distributions of stable OpenJDK updates
On 24.05.19 20:29, Martijn Verburg wrote:
> On Fri, 24 May 2019 at 15:40, tony mancill <tmancill@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
Reply to: