21

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] 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.

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.

Troubleshooting

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:

alsa-topology-conf: Installed: 1.2.5.1-2 Candidate: 1.2.5.1-2 Version table: *** 1.2.5.1-2 200 200 http://http.us.debian.org/debian sid/main amd64 Packages 100 /var/lib/dpkg/status 1.2.5.1-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 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:

alsa-topology-conf: Installed: 1.2.5.1-2 Candidate: 1.2.5.1-2 Version table: *** 1.2.5.1-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

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 ?

Improve this question
6
  • apt policy seems to show that you're mixing Debian and Ubuntu repositories. I wouldn't recommend that. Can you show the set of repositories you've got configured? Commented Jun 27, 2022 at 6:47
  • I think you need a pin for jammy too. Debian says stable is 100 but I don't know about Ubuntu Commented Jun 27, 2022 at 7:00
  • 2
    pinning above 1000 allows downgrades (though what is described shouldn't. Are there other pins?). Then the actual problem is warned there: wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian Commented Jun 27, 2022 at 8:57
  • 1
    Not only is it not something to be recommended, mixing repos, or even individual packages, from different distros is something to be actively discouraged and avoided. In short, it's a bad idea. A terrible idea. You're currently experiencing just one of the inevitable problems it causes, conflicts between versions of similar packages. Other problems result from differences & incompatibilities in the packaging policies (standards, expectations, unwritten "rules", interactions between packages, etc) of the different distros, and these problems can range from subtle to extremely obvious. Commented Jun 27, 2022 at 9:29
  • The best advice is "Don't Do That". Since you've already done it, the second best advice is "undo it if you can", even if that means backing up your data & config files, reformatting and re-installing from scratch (this time picking only a single distro and sticking to it). It can be a lot harder to fix the subtly things-don't-work-quite-right broken than the clearly and obviously broken. Commented Jun 27, 2022 at 9:33

2 Answers 2

Reset to default
29

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
Improve this answer
7
  • To clarify, I never downgraded anything, because all of the 'downgradable' packages are exactly the same packages I have installed. They are just identified incorrectly as originating from the lesser-priority repo, instead of it's actual source. I get your point thought about them not being the same. Commented Jun 27, 2022 at 20:57
  • As for xscreensaver specifically, I think you're right, as it seems to have been upgraded recently to the 6.x version in Ubuntu. It wasn't the case for a long time. Commented Jun 27, 2022 at 20:58
  • 1
    You actually did help me identify the issue. And I messed up in my description. Originally I listed in my question that the name was sid.list, it was acutally debian.sid.list, which comes up before pop_os..... Renaming the file to zzz.sid.list places it last and the issue is resolved. I've modified the question to reflect my shortcomings. Commented Jun 27, 2022 at 21:15
  • 1
    +1. Also worth noting is that an APT::Default-Release setting in an apt.conf file is enough for most needs and is a lot less hassle than mucking about with pinning values. e.g. I have repos for both sid (unstable) and experimental in my sources.list. I also have APT::Default-Release "unstable";. Only packages from "unstable" will be installed - nothing from experimental will ever be installed unless I explicitly tell apt to do so with -t experimental. I rarely ever do that, most commonly for nvidia driver updates (as they can sit in experimental for ages before migrating to sid). Commented Jun 28, 2022 at 1:48
  • 1
    maybe, dunno. I've been using A::D-R for as long as I can remember, initially on machines with stable + testing (or unstable), and continued on machines with unstable + experimental. The only time I bothered doing anything non-trivial with pinning was when I was trying to prevent gnome upgrading from gnome 2 to gnome 3. That was a major PITA, updating apt preferences almost daily for months until I gave up and let gnome 3 install (I tried to adapt to it but ended up switching to xfce). Trivial pinning jobs are easier to do with hold and manually installing specific versions Commented Jun 29, 2022 at 11:30
18

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:

pop-os-apps.sources pop-os-release.sources system.sources

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:

1.2.5.1-2 Candidate: 1.2.5.1-2 Version table: *** 1.2.5.1-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 1.2.5.1-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 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.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.