-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Debian/Ubuntu package versions contain codename which "break" dist upgrades #1315
Comments
Hmm.. interesting yes, so, IIUC, the situation in your case was;
And Interesting; hadn't received reports about this case before (a more common case is where users forget step I'm wondering how this is usually dealt with, and how the same would work for other packages. For example (taking ubuntu 20.04, 21.04, and 21.10 as an example); docker run -it --rm ubuntu:20.04 sh -c 'apt-get update -qq && apt-cache madison curl'
curl | 7.68.0-1ubuntu2.7 | http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
curl | 7.68.0-1ubuntu2.7 | http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages
curl | 7.68.0-1ubuntu2 | http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
docker run -it --rm ubuntu:21.04 sh -c 'apt-get update -qq && apt-cache madison curl'
curl | 7.74.0-1ubuntu2.3 | http://archive.ubuntu.com/ubuntu hirsute-updates/main amd64 Packages
curl | 7.74.0-1ubuntu2.3 | http://security.ubuntu.com/ubuntu hirsute-security/main amd64 Packages
curl | 7.74.0-1ubuntu2 | http://archive.ubuntu.com/ubuntu hirsute/main amd64 Packages
docker run -it --rm ubuntu:21.10 sh -c 'apt-get update -qq && apt-cache madison curl'
curl | 7.74.0-1.3ubuntu2 | http://archive.ubuntu.com/ubuntu impish/main amd64 Packages Installing/updating Incrementing the epoch would be an option of course, but feels like something to avoid, as we'd have to increment it for each distro (and version) separately 🤔 |
oh! I see I misread the ubuntu versions; looks like there, they used |
Looks like it's all a bit random: docker run -it --rm ubuntu:21.04 sh -c 'apt-get update -qq && apt-cache madison jq nano dpkg-sig golang'
jq | 1.6-2.1ubuntu1 | http://archive.ubuntu.com/ubuntu hirsute/main amd64 Packages
nano | 5.4-2build1 | http://archive.ubuntu.com/ubuntu hirsute/main amd64 Packages
dpkg-sig | 0.13.1+nmu4 | http://archive.ubuntu.com/ubuntu hirsute/universe amd64 Packages
golang | 2:1.16~0ubuntu1 | http://archive.ubuntu.com/ubuntu hirsute/main amd64 Packages
docker run -it --rm ubuntu:21.10 sh -c 'apt-get update -qq && apt-cache madison jq nano dpkg-sig golang'
jq | 1.6-2.1ubuntu2 | http://archive.ubuntu.com/ubuntu impish/main amd64 Packages
nano | 5.6.1-1build1 | http://archive.ubuntu.com/ubuntu impish/main amd64 Packages
dpkg-sig | 0.13.1+nmu4 | http://archive.ubuntu.com/ubuntu impish/universe amd64 Packages
golang | 2:1.17~0ubuntu1 | http://archive.ubuntu.com/ubuntu impish/main amd64 Packages |
I just realized that the epoch doesn't need to be increased since the codename is the very last portion of the version string and any version digit before that could be increased.
Any update to the package version would trigger an update even if the codename remains in use, so the issue is very minor. |
/cc @tianon I think this should be |
Doh, yep -- I'd probably do something like That |
Just to illustrate, my own packaging repository for |
ISTR that was added at some point when the switch was made to CalVer, but I'd have to do some digging in git history as I wasn't directly involved in those changes in packaging at the time. Looking if there's some logical number / value we could use for this; would In debian, that'd be
On Ubuntu, e.g.;
(basically, looking if there's something we could add, without having to add a manual number, for each distro and/or distro version 🤔) |
Yeah, source /etc/os-release
echo "$ID${VERSION_ID//./}" That gives values like |
Expected behavior
A dist-upgrade/full-upgrade (e.g. buster->bullseye) updates the currently installed docker packages to those built for the target OS version.
Actual behavior
A dist-upgrade does not update docker packages. I don't think this currently breaks anything because the builds seem to be compatible, but the package versioning scheme could be reconsidered.
The reason for this is that the package version contains the release codename which are not alphabetically ordered:
5:20.10.9~3-0~debian-buster
is considered newer than5:20.10.9~3-0~debian-bullseye
A solution could be to use the release version instead of codename, but I think it requires an epoch update.
Steps to reproduce the behavior
Replace buster repo's with bullseye repo's and perform a dist-upgrade:
Output of
docker version
:Output of
docker info
:Additional environment details (AWS, VirtualBox, physical, etc.)
The text was updated successfully, but these errors were encountered: