[Packaging] How does APT determine a package to be a downgrade?

[JRMoore]

I reckon the question title is at the very least odd, but I am confused myself when packages appear to have the same version as those installed.

I am looking into packaging for Debian, when it comes to writing the instructions on how to build a piece of software it seems it is not as straightforward as for other package formats, so I began by looking into a package already made, rebuilding Bash (tried others afterwards).

I think I followed the appropriate steps: dpkg-dev and devscripts are installed, source repos enabled, package source checked out (apt source bash) and its build dependencies too (apt build-dep bash). I used the --no-sign flag for dpkg-buildpackage because I am just looking into things for the moment. Build was successful and I have deb archives I can install, but APT regards them as downgrades (in capital letters). How come? What am I missing?

Code: Select all

$ apt list --installed | grep bash

bash-completion/oldstable,now 1:2.11-2 all [installed]
bash/oldstable,now 5.1-2+deb11u1 amd64 [installed]

$ apt-cache madison bash

bash | 5.1-2+deb11u1 | http://mirror.nl.leaseweb.net/debian bullsege/main amd64 Packages
bash | 5.1-2+deb11u1 | http://mirror.nl.leaseweb.net/debian bullseye/main Sources

$ dpkg-deb -I bash_5.1-2+deb11u1_amd64.deb

new Debian package, version 2.0.

[... trimmed ...]

Package: bash
Version: 5.1-2+deb11u1

[... trimmed ...]

$ apt install ./bash_5.1-2+deb11u1_amd64.deb

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'bash' instead of './bash_5.1-2+deb11u1_amd64.deb'
Suggested packages:
  bash-doc
The following packages will be DOWNGRADED:
  bash
0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 2 not upgraded.

[... trimmed ...]

Image with the full output, the important bits are above though.

That build was performed as root, but I have also tried as an unprivileged user using fakeroot. Even setting up a trivial local repo, ensuring it had more priority than the official ones and install from there, in case the trigger was the package not belonging to a repo, leads to APT not seeing it as a reinstallation but a downgrade.

[sunrat]

Please post terminal output as text in code tags, not images.
If you can replace it in your post it would be appreciated.

I have no idea about your issue. It seems to be the same version. I think it would be good practice to give your locally built package a different version number.

[Head_on_a_Stick]

Try

Code: Select all

dch -v 5.1-2.1

It doesn't follow SemVer but it should work and won't stop the next upgrade.

If you want to stop it from being upgraded (why?) add an epoch:

Code: Select all

dch -v 1:5.1-2

But you probably don't want that. Epochs should almost never be used.

Not sure which documentation you're following but I use https://www.debian.org/doc/manuals/debmake-doc/ & https://www.debian.org/doc/debian-policy/ with lintian(1) checking the packages.

[JRMoore]

Thank you both! Sorry, @sunrat for the full image in the post, it should be fixed now.

I didn't want to prevent it from being upgraded @Head_on_a_Stick, not any package and much less one that central to it all, I was confounded about how APT works. I am still unsure about what it is that leads the package manager to determine an installation is a downgrade, but as I am delving into it, I noticed a change in the build flags trips it.

My CFLAGS had -ftree-vectorize, differing from the standard ones as it doesn't seem to be enabled at O2 on GCC 10.2, leading to different binaries. Extracting the control part of the resulting package and comparing it to the one from the repo I noticed some changes:

- Installed-Size was different.
- MD5 hashes for bash, bashbug and clear-console were different.
- The preinst binary differs too, since it is not a script in this package I guess it used that compilation flag as well.

Could that be it? Differing hashes compared to the repo package? Perhaps added to the fact that the one in the repository is signed. I see that version comparison is not the only variable when it comes to determining if an installation is an upgrade, downgrade or the same, but I don't know what else is.

It is more of a curiosity though, I won't be running into this when I package the program I need to as every new version would always be an upgrade. By the way, thanks for the links!

[stevepusser]

I have a theory that the default configuration for apt gives a higher priority to a package from an actual repository, even if your local package is the same version. It would make sense from a security viewpoint.

[CwF]

I have a theory that the default configuration for apt gives a higher priority to a package from an actual repository, even if your local package is the same version. It would make sense from a security viewpoint.

The literal order in sources.list makes that choice. If all factors are the same the first listing wins.