I think so, yes.

Great. I will mark as solved. Thanks once again HoaS for your help. Thanks also to aitor; your way did stop Synaptic from updating it.

Looks like Synaptic & apt-mark both use the dpkg database whereas apt & apt-get will check the pinning and aptitude will accept either input.

Check

While waiting for your reply, I went ahead and deleted the preferences folder I created with that file in it, and kept the file you recommend in preferences.d, then rebooted. Synaptic is still showing the old version of sudoku I use as the latest version. I also checked apt update and apt policy gnome-sudoku and that checked out good also. So I guess all is well??

dpkg --get-selections gnome-sudoku

I think both Synaptic's package lock option and apt-mark hold will change that setting to

gnome-sudoku					hold

To confirm this run

sudo dpkg --set-selections <<<"gnome-sudoku install"

And check dpkg --get-selections gnome-sudoku, apt-mark showhold and Synaptic itself to see if this changes the "Latest Version" shown in your screenshot.

Revert the change with

sudo dpkg --set-selections <<<"gnome-sudoku hold"

Perhaps that is needed as well as APT pinning for it to work with both Synaptic and apt/apt-get/aptitude.

EDIT: it seems aptitude uses either the dpkg database or APT's pin values. This is confusing.

Looks good to me :-)

Great. Just one more thing. Now this is what I get in Synaptic. It shows the old version that I use as the latest version. Does this mean I can undo the first thing I did earlier? Or should I just leave well enough alone?

ron@ron:~$ sudo apt update
[sudo] password for ron: 
Hit:1 http://deb.devuan.org/merged chimaera InRelease
Get:2 http://deb.devuan.org/merged chimaera-security InRelease [21.5 kB]
Hit:3 http://deb.devuan.org/merged chimaera-updates InRelease
Hit:4 http://deb.devuan.org/merged chimaera-backports InRelease
Fetched 21.5 kB in 3s (7,144 B/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.

ron@ron:~$ apt policy gnome-sudoku
gnome-sudoku:
  Installed: 1:3.22.2-1
  Candidate: 1:3.22.2-1
  Version table:
     1:3.38.0-1 500
        500 http://deb.devuan.org/merged chimaera/main amd64 Packages
 *** 1:3.22.2-1 501
        100 /var/lib/dpkg/statu

Is everything now correct?

I have no idea about Synaptic or how that works, sorry. I never use it.

There is no pinning for that package. If you run apt update followed by apt list --upgradable I think gnome-sudoku will still be marked for upgrade to the chimaera version.

I only update via Synaptic, and here's what happens in it. It doesn't get updated. But are you saying if I do an update via the terminal it will get updated?

This is what I got from your commands:

ron@ron:~$ sudo apt update
[sudo] password for ron: 
Hit:1 http://deb.devuan.org/merged chimaera InRelease
Get:2 http://deb.devuan.org/merged chimaera-security InRelease [21.5 kB]
Hit:3 http://deb.devuan.org/merged chimaera-updates InRelease
Hit:4 http://deb.devuan.org/merged chimaera-backports InRelease
Fetched 21.5 kB in 2s (9,148 B/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
1 package can be upgraded. Run 'apt list --upgradable' to see it.

ron@ron:~$ apt list --upgradable
Listing... Done
gnome-sudoku/stable 1:3.38.0-1 amd64 [upgradable from: 1:3.22.2-1]
N: There is 1 additional version. Please use the '-a' switch to see it

$ apt policy gnome-sudoku
gnome-sudoku:
  Installed: 1:3.22.2-1
  Candidate: 1:3.38.0-1
  Version table:
     1:3.38.0-1 500
        500 http://deb.devuan.org/merged chimaera/main amd64 Packages
 *** 1:3.22.2-1 100
        100 /var/lib/dpkg/status

There is no pinning for that package. If you run apt update followed by apt list --upgradable I think gnome-sudoku will still be marked for upgrade to the chimaera version.

The apt-mark hold suggestion doesn't work either in my testing but this does:

Package: gnome-sudoku
Pin: version 1:3.30.0-2
Pin-Priority: 501

^ Save that under /etc/apt/preferences.d/gnome-sudoku.pref, run apt update and check the Candidate line in the output of apt policy gnome-sudoku. It should prefer the old version with that setting.

The man page states that a pin value of 1001 would be needed because the beowulf version constitutes a downgrade but that doesn't seem to be the case in my tests with a Debian bullseye chroot. If your system behaves differently please report back, I would appreciate the feedback. TIA.

If you want to keep the package updated from beowulf then add these lines to /etc/apt/sources.list:

deb http://deb.devuan.org/merged beowulf main
deb http://deb.devuan.org/merged beowulf-updates main
deb http://deb.devuan.org/merged beowulf-security main

Then change the Pin: version line in /etc/apt/preferences.d/gnome-sudoku.pref to

Pin: release beowulf

And remember to run apt update afterwards.

Because it's very complicated to use (see apt_preferences(5) for the official documentation, the Debian wiki page is bollocks) and it's far too easy to break your system if you don't know what you're doing.

I've just got the Debian buster version of gnome-sudoku running from a chroot in my Alpine system with no issues but the chroot takes up almost a gigabyte of disk space, which is ridiculous.

Either location should work.

Check the pinning with

apt policy
apt policy gnome-sudoku

I would consider running the program from a chroot because pinning makes me nervous but that would take significantly more disk space.

Here's the output:

$ apt policy
Package files:
 100 /var/lib/dpkg/status
     release a=now
 100 http://deb.devuan.org/merged chimaera-backports/non-free amd64 Packages
     release v=4.0,o=Devuan Backports,a=stable-backports,n=chimaera-backports,l=Devuan Backports,c=non-free,b=amd64
     origin deb.devuan.org
 100 http://deb.devuan.org/merged chimaera-backports/contrib amd64 Packages
     release v=4.0,o=Devuan Backports,a=stable-backports,n=chimaera-backports,l=Devuan Backports,c=contrib,b=amd64
     origin deb.devuan.org
 100 http://deb.devuan.org/merged chimaera-backports/main amd64 Packages
     release v=4.0,o=Devuan Backports,a=stable-backports,n=chimaera-backports,l=Devuan Backports,c=main,b=amd64
     origin deb.devuan.org
 500 http://deb.devuan.org/merged chimaera-updates/main amd64 Packages
     release v=4.0.0,o=Devuan,a=stable-updates,n=chimaera-updates,l=Devuan,c=main,b=amd64
     origin deb.devuan.org
 500 http://deb.devuan.org/merged chimaera-security/main amd64 Packages
     release v=4.0,o=Devuan,a=stable-security,n=chimaera-security,l=Devuan-Security,c=main,b=amd64
     origin deb.devuan.org
 500 http://deb.devuan.org/merged chimaera/contrib amd64 Packages
     release v=4.0,o=Devuan,a=stable,n=chimaera,l=Devuan,c=contrib,b=amd64
     origin deb.devuan.org
 500 http://deb.devuan.org/merged chimaera/non-free amd64 Packages
     release v=4.0,o=Devuan,a=stable,n=chimaera,l=Devuan,c=non-free,b=amd64
     origin deb.devuan.org
 500 http://deb.devuan.org/merged chimaera/main amd64 Packages
     release v=4.0,o=Devuan,a=stable,n=chimaera,l=Devuan,c=main,b=amd64
     origin deb.devuan.org
Pinned packages:
     refractainstaller-base -> 9.5.6 with priority 1001
     refractainstaller-gui -> 9.5.6 with priority 1001

and

$ apt policy gnome-sudoku
gnome-sudoku:
  Installed: 1:3.22.2-1
  Candidate: 1:3.38.0-1
  Version table:
     1:3.38.0-1 500
        500 http://deb.devuan.org/merged chimaera/main amd64 Packages
 *** 1:3.22.2-1 100
        100 /var/lib/dpkg/status

Why does pinning make you nervous? My concern is just to be sure that nothing else gets blocked from updating.

Check the pinning with

apt policy
apt policy gnome-sudoku

I would consider running the program from a chroot because pinning makes me nervous but that would take significantly more disk space.

I forgot the extension. So, you don't need to create any additional folder, because /etc/apt/preferences.d is the right place to edit the file.

Well everything seems to be working right. I had some updates today, and sudoku was marked as not to be upgraded. Everything else updated okay. Should I just leave well enough alone, or put that file in preferences.d and delete the preferences folder I created?

BTW, there was no "preferences" folder in /etc/apt, so I created one. Is that normal? There is a "preferences.d" folder.

I forgot the extension. So, you don't need to create any additional folder, because /etc/apt/preferences.d is the right place to edit the file.

BTW, there was no "preferences" folder in /etc/apt, so I created one. Is that normal? There is a "preferences.d" folder.