3 ms·

As 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 ar

by chungy 7y ago

As 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.java.net/jdk8u/jdk8u/tags https://hg.openjdk.java.net/jdk-updates/jdk11u/tags https://hg.openjdk.java.net/jdk-updates/jdk11u/tags The "-ga" tags do pretty clearly delineate official releases, but they also get pushed to the public repository well (often weeks) after Oracle posts official binaries for these releases. It is confusing and makes it not all that mysterious that distribution packaging will take the best that they can see for doing a clean build, as they like to do. It would help quite a lot if the +1/+2/+3/etc releases were instead delineated with "-alpha1", "-beta1", "-rc1" tags. Much clearer that they aren't meant to be production.

djsumdog 7y ago
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.
- repolfx 7y ago
  It's an age old problem. Upstreams were complaining (legitimately) about how Linux distributions would (re)package their software and break it along the way 20 years ago. Broken packages in Docker being pulled from Debian is no surprise, it was ever thus.
smarks 7y ago
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.

by chungy 7y ago

djsumdog 7y ago

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.

repolfx 7y ago
It's an age old problem. Upstreams were complaining (legitimately) about how Linux distributions would (re)package their software and break it along the way 20 years ago. Broken packages in Docker being pulled from Debian is no surprise, it was ever thus.

smarks 7y ago

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.