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