There don't seem to be any debian emails about it: https://lists.debian.org/debian-java/2019/05/threads.html
Debian does not pull things from random Docker containers.
The random Docker containers are using Debian's own packages.
Mystery meat OpenJDK builds strike again
11–20 of 56 posts
Re: Mystery meat OpenJDK builds strike again
#12As an observer, not any kind of authority: The release methodology of OpenJDK from Oracle is obscure at best, and it is hard to imagine how package managers are supposed to cope. I notice both of these examples come with Debian version strings attached, and they likely build from tags in the version control repository. As example, in these two links: https://hg.openjdk.java.net/jdk8u/jdk8u/tags https://hg.openjdk.jav…
I think this has lees to do with the OpenJDK team and more to do with the part of the Docker team and/or community that maintain this repo and not pulling correct release versions.
I knew someone who worked at Gradle and noticed how RedHat did all their own gradle packaging that broke everything they had in their offical rpms and spec files.
Some projects like Elastic Search maintain their own v2 repos on their own domain (all there's are mirrored on Docker hub but their docs point to their own repo) and other projects have official Docker hub accounts (like Jenkins).
I'm guessing the right solution might be Docker hub working with the OpenJDK guys so they maintain their own organization on Docker hub and integrate building and pushing to it from their own CI.
Re: Mystery meat OpenJDK builds strike again
#13Re: Mystery meat OpenJDK builds strike again
#14Not completely related, but this is one of the reasons why I prefer to add commits bumping the version number when a release is made instead of before–it means that any builds made from source don't have version number they shouldn't.
It took me a long time to understand why Maven uses version strings like 4.2.1-SNAPSHOT but this is exactly why it's useful.
(The standard practice is to strip the "-SNAPSHOT" off for the release commit, then stick it back on for the next commit, but with a bumped minor version. Both commits are then pushed at once, so stuff built locally always is marked as a SNAPSHOT.)
Re: Mystery meat OpenJDK builds strike again
#15Re: Mystery meat OpenJDK builds strike again
#16Not completely related, but this is one of the reasons why I prefer to add commits bumping the version number when a release is made instead of before–it means that any builds made from source don't have version number they shouldn't.
It took me a long time to understand why Maven uses version strings like 4.2.1-SNAPSHOT but this is exactly why it's useful. (The standard practice is to strip the "-SNAPSHOT" off for the release commit, then stick it back on for the next commit, but with a bumped minor version. Both commits are then pushed at once, so stuff built locally always is marked as a SNAPSHOT.)
[deleted]
Re: Mystery meat OpenJDK builds strike again
#17As an observer, not any kind of authority: The release methodology of OpenJDK from Oracle is obscure at best, and it is hard to imagine how package managers are supposed to cope. I notice both of these examples come with Debian version strings attached, and they likely build from tags in the version control repository. As example, in these two links: https://hg.openjdk.java.net/jdk8u/jdk8u/tags https://hg.openjdk.jav…
Note that Oracle has nothing to do with these releases or builds. Red Hat is now the maintainer of OpenJDK 8u and 11u release families. But this isn’t Red Hat’s fault either.
By default, the OpenJDK builds put something obvious like “-internal” into the version string, and you have to override it explicitly if you are intending to produce an official build. Whoever made these builds overrode the version string to make them look like official releases, when in fact they don’t correspond to official release tags in the source.
In other cases there may have been a delay between the appearance of an official binary and the appearance of the release tag in the source tree, but that’s not the issue here.
Re: Mystery meat OpenJDK builds strike again
#18To be fair, I wouldn't have known what "WE" meant either. Why not "WIP" instead?
Re: Mystery meat OpenJDK builds strike again
#19Unrelated, but one thing that's confused me, as someone who doesn't really use Docker. I don't think of a programming language as being the thing upon which I would base my layers of containers. My expectation, as someone coming from not-containers, would be that I should first start with a core-libraries container, _then_ a language container, and then packages on top. Having this clarity of composition, I think, is…
The openjdk container is based on a distribution container and publishes multiple versions for different distributions (debian, alpine, windows, slim debian, old debian version, etc.). Users then base their containers on top of an openjdk container and add their packages dependencies to their docker files. The issue here is that the language container seems to have pinned against a specific non-release version of openjdk.
Re: Mystery meat OpenJDK builds strike again
#20Unrelated, but one thing that's confused me, as someone who doesn't really use Docker. I don't think of a programming language as being the thing upon which I would base my layers of containers. My expectation, as someone coming from not-containers, would be that I should first start with a core-libraries container, _then_ a language container, and then packages on top. Having this clarity of composition, I think, is…
Core library of what programming language, if you haven't picked a language yet?
I think the OP's talking about stuff like Qt, OpenGL, BLAS/LAPACK.