Getting rid of "The following packages will be DOWNGRADED"
I’ll start by stating, I’m pretty sure this is a unique mess of my own design, but I hope someone encountered this and might be able to help.
My laptop runs Pop!_OS 22.04 (Based on Ubuntu Jammy). I really like the xscreensaver packages, but the Debian/Ubuntu/Pop!_OS release repos contain an outdated version, and only sid (aka Unstable) contains the updated package*.
No fret, that’s why pinning exists, and so this is how I have it setup:
Package: * Pin: release a=unstable Pin-Priority: 200
Package: xscreensaver* Pin: release a=unstable Pin-Priority: 2000
deb [arch=amd64] http://http.us.debian.org/debian sid main contrib non-free
This actually works, at this point running
sudo apt install xscreensaver installs the updated versions.
However, there is a strange side-effect.
When I run
sudo apt update followed by
sudo apt upgrade, I get the following output:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be DOWNGRADED:
alsa-topology-conf appmenu-gtk-module-common aspell-en ca-certificates
chrome-gnome-shell dictionaries-common dns-root-data emacsen-common folks-common
fonts-arphic-ukai fonts-noto-cjk fonts-noto-cjk-extra fonts-noto-color-emoji
fonts-urw-base35 friendly-recovery gir1.2-flatpak-1.0 gir1.2-gdkpixbuf-2.0
gir1.2-graphene-1.0 gir1.2-gtksource-4 gir1.2-polkit-1.0 gir1.2-secret-1
gir1.2-soup-2.4 gsfonts gsfonts-x11 hunspell-ar hunspell-de-at-frami
hunspell-de-ch-frami hunspell-de-de-frami hunspell-en-au hunspell-en-ca hunspell-en-gb
hunspell-en-us hunspell-en-za hunspell-es hunspell-fr hunspell-fr-classical hunspell-it
hunspell-pt-br hunspell-pt-pt hunspell-ru hyphen-de hyphen-en-gb hyphen-es hyphen-fr
laptop-detect liba52-0.7.4 libappmenu-gtk2-parser0 libbytesize-common libffi8
libflatpak-dev libgl1 libgles2 libgutenprint-common libgweather-4-0 libio-stringy-perl
libjs-jquery libldacbt-abr2 libmpcdec6 libmysofa1 libopengl0 libpolkit-gobject-1-0
libsndio7.0 libsoup-gnome2.4-1 libtermkey1 libvterm0 libwacom-common libxkbcommon0
mythes-ar mythes-de mythes-de-ch mythes-en-au mythes-en-us mythes-es mythes-fr
mythes-it mythes-pt-pt mythes-ru neovim-runtime netbase pass policykit-1 poppler-data
powermgmt-base printer-driver-all python3-certifi python3-fido2 python3-jinja2
python3-launchpadlib python3-lazr.uri python3-macaroonbakery python3-more-itertools
python3-pkg-resources python3-pyatspi python3-rfc3339 python3-setuptools python3-tz
python3-wheel python3-ykman sensible-utils sgml-base sgml-data sound-icons ssl-cert
tpm-udev ucf update-inetd va-driver-all wamerican wbrazilian wbritish wfrench witalian
wngerman wogerman wspanish wswiss xfonts-base xml-core yubikey-manager
0 upgraded, 0 newly installed, 125 downgraded, 0 to remove and 0 not upgraded.
Need to get 257 MB/283 MB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
This also throws off Pop!_OS Shop’s update count, with these packages showing as pending Operating System Updates.
Some data I collected while attempting to troubleshoot this.
/etc/apt/sources.list.d/debian.sid.list and running
sudo apt update resolves the issue, so I know it’s just a miscalculation/flawed logic somewhere.
Focusing on the the first package in the list
Although I know the error is completely superficial, at first I thought
apt somehow tracks where (which repo) the package came from, so I removed, cleaned-up, then reinstalled the package. Didn’t make a difference.
sudo apt remove alsa-topology-conf
sudo apt clean
sudo apt update
sudo apt install alsa-topology-conf
apt policy alsa-topology-conf, the results are:
alsa-topology-conf: Installed: 126.96.36.199-2 Candidate: 188.8.131.52-2 Version table: *** 184.108.40.206-2 200 200 http://http.us.debian.org/debian sid/main amd64 Packages 100 /var/lib/dpkg/status 220.127.116.11-2 501 501 http://us.archive.ubuntu.com/ubuntu jammy/main amd64 Packages 501 http://us.archive.ubuntu.com/ubuntu jammy/main i386 Packages
It seems that both
jammy have the exact same version, and for some reason,
apt matches the package to the
200 priority, instead of the
501 priority entry.
/etc/apt/sources.list.d/debian.sid.list removed, the output looks like this:
alsa-topology-conf: Installed: 18.104.22.168-2 Candidate: 22.214.171.124-2 Version table: *** 126.96.36.199-2 501 501 http://us.archive.ubuntu.com/ubuntu jammy/main amd64 Packages 501 http://us.archive.ubuntu.com/ubuntu jammy/main i386 Packages 100 /var/lib/dpkg/status
The following are related questions with similar situations but none of the answers there helped me understand or resolve this.
- apt pinning priority restricted
- Debian 10: Why some SSL packages will be downgraded?
- How to get rid of "Packages were downgraded and -y was used without –allow-downgrades" apt message
I’ve tried all of the answers in the above questions, but none seems to either be relevant or work out.
Does anyone have any suggestion on how to reconcile this so that the system will not constantly think that these packages need to be DOWNGRADED ?
The basic answer is that you’re doing something that you shouldn’t, namely mixing repositories across releases (and distribution). Pulling in Debian packages in an Ubuntu-based distribution is a bad idea.
xscreensaver is available in later versions of Ubuntu, which would be less dangerous to use, but even that’s a bad idea.
Given all the investigation you’ve done, and the detail you’ve provided, it’s worth explaining the behaviour you’re seeing here. All the packages that are offered for “downgrade” have the shared property of being available in the same version in Debian and Ubuntu; however, they are not the same packages, since all packages imported from Debian are rebuilt in Ubuntu.
The first feature of
apt which comes into play here is that pin-priorities only choose versions. For any package available in different versions in your repositories, the pin-priorities will distinguish between them. For any package available in the same version in your repositories, they won’t. The next feature then applies: when multiple repositories provide the same version, the first one listed wins. This combines with another feature of
apt, which is that a package installed with a given hash will be replaced by a repository package with the same version if the hashes don’t match (there’s a Q&A about that somewhere here, but I can’t find it right now).
The result of all this is that for all packages provided by Pop!_OS (Ubuntu under the hood), whose versions in Jammy exactly match the current version in Debian unstable,
apt will consider replacing them with the Debian version. I’m not sure why it identifies them as downgrades.
If you were to go ahead with this, you’d replace a number of Pop!_OS packages with their Debian “equivalents”; there’s a decent chance that that would actually work, but there’s also the possibility that subtle differences in the libraries used would cause problems. You’d end up with a wholly untested setup.
To undo this, you should remove
sid.list, update your repositories, and explicitly re-install any package you “downgraded”:
sudo apt reinstall alsa-topology-conf
Thank you Stephen Kitt
To be clear, Stephen Kitt‘s
answer is the selected one.
However, as the OP I’m adding the specifics to resolving
my particular issue (in case anyone else finds it interesting).
As Stephen so graciously and patiently pointed out what is quite well
documented, but yet I failed to understand/read properly:
Choosing which package to grab is a 2 phased process:
- The priorities determine which version to grab.
- Only then
aptgrabs the first repo that has that specific version listed.
- First it looks in
- Next it looks in
/etc/apt/sources.list.ddir, sorting the files in
the directory in lexical order (basically what
lsdoes by default)
- First it looks in
Not specified in my question, was the fact that the Pop!_OS sources files, were listed in
/etc/apt/sources.list.d dir and they are named:
pop-os-apps.sources pop-os-release.sources system.sources
This means that
debian.sid.list when sorted with the list above, will still show up before
system.sources which is where Ubuntu’s Jammy repo is specified.
Resolving the issue – an answer
To resolve the particular scenario I described in my question, the solution for me was to rename
zzz.sid.list which will ensure that the packages in
sid will always be chosen last.
Here is how
apt policy alsa-topology-conf looks like after this fix:
188.8.131.52-2 Candidate: 184.108.40.206-2 Version table: *** 220.127.116.11-2 501 501 http://us.archive.ubuntu.com/ubuntu jammy/main amd64 Packages 501 http://us.archive.ubuntu.com/ubuntu jammy/main i386 Packages 100 /var/lib/dpkg/status 18.104.22.168-2 200 200 http://http.us.debian.org/debian sid/main amd64 Packages 200 http://http.us.debian.org/debian sid/main i386 Packages
The correct answer
When possible, this shouldn’t be needed, and specifically with this latest version of Pop!_OS, the underlying Ubuntu version has finally upgraded the xscreensaver packages and they actually match those of
Long story short, I thought (from past experience) I needed to hack the system, while at this particular situation, I didn’t need to, and the solution was to not try.
But then again – I learn best when I break things, and this was an awesome lesson, and I thank the people who took the time to read and respond.