[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:

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:

> 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.


Reply to: