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.

The Setup

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:

/etc/apt/preferences.d/unstable-200 file:

Package: *
Pin: release a=unstable
Pin-Priority: 200

/etc/apt/preferences.d/xscreensaver-2000 file:

Package: xscreensaver*
Pin: release a=unstable
Pin-Priority: 2000

/etc/apt/sources.list.d/debian.sid.list file:

deb [arch=amd64] 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.

The problem

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
  hyphen-it hyphen-pt-br hyphen-pt-pt ieee-data javascript-common klibc-utils
  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.

Removing /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 alsa-topology-conf:

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

Running apt policy alsa-topology-conf, the results are:

  Version table:
 *** 200
        200 sid/main amd64 Packages
        100 /var/lib/dpkg/status 501
        501 jammy/main amd64 Packages
        501 jammy/main i386 Packages

It seems that both sid and jammy have the exact same version, and for some reason, apt matches the package to the 200 priority, instead of the 501 priority entry.

With /etc/apt/sources.list.d/debian.sid.list removed, the output looks like this:

  Version table:
 *** 501
        501 jammy/main amd64 Packages
        501 jammy/main i386 Packages
        100 /var/lib/dpkg/status

Related questions

The following are related questions with similar situations but none of the answers there helped me understand or resolve this.

I’ve tried all of the answers in the above questions, but none seems to either be relevant or work out.

My question

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 ?

Asked By: Lockszmith


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
Answered By: Stephen Kitt

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:

  1. The priorities determine which version to grab.
  2. Only then apt grabs the first repo that has that specific version listed.
    • First it looks in /etc/apt/sources.list file
    • Next it looks in /etc/apt/sources.list.d dir, sorting the files in
      the directory in lexical order (basically what ls does by default)

My problem

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:


This means that sid.list or 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 sid.list to 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:   Candidate:   Version table:  *** 501
        501 jammy/main amd64 Packages
        501 jammy/main i386 Packages
        100 /var/lib/dpkg/status 200
        200 sid/main amd64 Packages
        200 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 sid.

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.

Answered By: Lockszmith