Hi Martijn,
> understanding of how OpenJDK source(s) map onto the Debian packaging
> system/channels. It's been a failing on the OpenJDK community side to help
the Debian side of this, as relates to the releases, is this:
Debian 9 (stretch), the current stable release, shipped with
OpenJDK 8, so it will continue to receive security fixes for
OpenJDK 8 throughout its supported lifetime.
Debian 10 (buster), currently prerelease, will ship with
OpenJDK 11, and thus receive updates for OpenJDK 11.
stretch-backports is a suite which corresponds to backports
of those packages that are, at the time of backporting, in
buster. “backports” here basically means that the exact(!)
package is rebuilt in the previous distribution, and the only
allowed changes are those necessary to make it build and work
there. Debian backports also operate under the expectation
that, whenever a new version is uploaded to or migrates¹ to
the origin suite, the backport will be updated (or removed,
if backporting is no longer possible).
Now, buster is still prerelease, which means that the packages
in stretch-backports are also prerelease right now. (We’re
expecting to release within $smallnum weeks, though.) But they
will eventually be identical to what will be shipped with, and
supported in, buster.
① “migrate”: the testing distribution is a bit of special case,
as packages are not normally directly uploaded there, but to
unstable first and then migrate after a period of time in which
bugs can be identified, and it will not migrate if it depends
on any other packages that cannot migrate (unless the version
already in testing satisfies the dependency).
Now I’m not involved in what actually goes into the packages
in the first place, but the plan (a bit taken off path by the
ftpmasters misinterpreting a removal request for some builds
of OpenJDK 8 in unstable as a request to remove OpenJDK 8 in
its entirety) is to prepare updated versions of all supported
JDKs in unstable, then, when no problems are shown, to upload
those to oldstable-security or stable-security or testing² as
needed, and then (following backports policy) updating the
backports accordingly (oldstable-backports from stable-security,
stable-backports from testing).
② normally by letting it migrate, or, during pre-release freeze,
requesting an unblock to allow the package to migrate
The intent is to package stable versions for actual Debian
releases, then apply necessary security fixes afterwards
(because in Debian, we never³ introduce new versions into
an already released version as part of the stability promise).
I assume part of the problem is the difficulty of identifying
what’s stable (and get the corresponding addons for e.g. the
ARM architectures), but, as doko said, trust the content, not
the label. Versions of software Debian ships don’t necessarily
correspond to the versions in other distributions of the same
software, but they are those tested and integrated with the
rest of the distribution, and those that will be supported by
the Debian maintainers and security team.
As a user, I’d rather have a, say, 8u212 upstream prerelease
that’s supported by the security team (and that works for our
use cases in building and running software in Java™, and that
integrates with the rest of the software shipped by Debian)
than to blindly install new upstream versions, especially if
those introduce regressions. (It was bad enough when those
JAR manifest “security” patches broke builds for ages.)
③ This is not entirely true, admittedly: for select software,
such as “modern” web browsers, where supporting the versions
in stable over the lifetime of a release is not possible at
all, new versions are allowed into stable-security, but this
deviates from both the security and the stability promises
and is communicated to users as a compromise (we rather ship
an unsupported but recent version than none at all, so our
users may get the software) but we prefer to do that only
when the regular way of retrofitting security updates only
is not at all possible.
For OpenJDK and some other softwares, it is understood that
upstream branches containing only security fixes for the
released version is acceptable for uploads of “new” versions
(as long as those are really security and critical bug fixes
only, not new versions or features; and even then, sometimes
things break in a bad way, which we’d like to avoid).
Ah, and here comes the reasoning why an 8u212 prerelease is
no problem (as long as it’ll eventually be replaced by the
actual release or something newer): when an upstream branch
is considered to be comprised of only security and critica
bug fixes, the releases upstream cuts off that branch are
just snapshots at some given point in time, and a prerelease
would be just as stable, as surely upstream would only have
applied a patch to that branch only if it addresses either
a security problem or a critical bug and it had already been
tested in the latest development/feature branch. (Does this
make sense? If not, please DO tell, and I’ll try to explain
some more, as this is a core point and somewhat critical.)
Full disclosure: I’m a Debian Developer and maintainer of a
couple of packages, but not of any of the core Java packages.
In my dayjob, I’m a user of those, package some fringe ones
and occasionally help out.
Please listen to doko for anything authoritative to OpenJDK
packaging, and for anything to do with Canonical/Ubuntu with
which I have nothing to do.
Something else to keep in mind: all this talking about a
specific “build” of Java, as that Azul person does, cannot
apply to Debian as we always build all software shipped in
Debian ourselves from source code. So it’s best to avoid
using the word “build” when discussing something with Debian.
I think terms that correspond to specific statuses of the
source code trees and branches would work better instead.
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 der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.
Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.
**********