19

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 ?

Lockszmith
  • 670
  • 5
  • 14
  • 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? – Chris Davies Jun 27 '22 at 06:47
  • I think you need a pin for jammy too. Debian says stable is 100 but I don't know about Ubuntu – Chris Davies Jun 27 '22 at 07:00
  • 2
    pinning above 1000 allows downgrades (though what is described shouldn't. Are there other pins?). Then the actual problem is warned there: https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian – A.B Jun 27 '22 at 08: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. – cas Jun 27 '22 at 09: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. – cas Jun 27 '22 at 09:33
  • @roaima, you are correct, I intentionally mixed those, but pinned it to a lower priority (200). For some reason, the lower priority is being picked up and marked as 'DOWNGRADE'. As for pinning jammy, I'll try that - it's currently at 500, which is the default from what I've found in all other resources. – Lockszmith Jun 27 '22 at 21:04

2 Answers2

27

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
Stephen Kitt
  • 434,908
  • 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. – Lockszmith Jun 27 '22 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. – Lockszmith Jun 27 '22 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. – Lockszmith Jun 27 '22 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). – cas Jun 28 '22 at 01:48
  • The only minor "catch" is that if you have two releases with the same name for some reason, they will both be considered to be the same release as far as APT::Default-Release is concerned. e.g. my mythtv box has official debian "unstable" AND the debian-multimedia "unstable" (because that's where the mythtv packages are). Probably for pinning too, since it works on release names. I dunno. I use apt-mark hold to manually control when/if myth and related packages are upgraded. – cas Jun 28 '22 at 01:51
  • @cas I would have thought an unstable/experimental combo wouldn’t need Default-Release either — experimental is “NotAutomatic”, which results in an automatic pin-priority of 1. (I agree that Default-Release is simpler in general!) – Stephen Kitt Jun 29 '22 at 10:57
  • 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 – cas Jun 29 '22 at 11:30
17

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.

Lockszmith
  • 670
  • 5
  • 14