While examining the snap packages that are installed in a system, I noticed that some packages have a duplicate, one having an over revision number while the other having a newer revision number. For such duplicated packages, my questions are:
- Why are they duplicated?
- Can I remove the older package to ensure better disk space management?
- How do I remove the older package?
Below are examples of packages that do and do not have duplicates:
$ du -hcs /var/lib/snapd/snaps/*
31M /var/lib/snapd/snaps/2048x_3.snap
286M /var/lib/snapd/snaps/atom_282.snap
4.0K /var/lib/snapd/snaps/bare_5.snap
72M /var/lib/snapd/snaps/bitwarden_58.snap
72M /var/lib/snapd/snaps/bitwarden_59.snap
196M /var/lib/snapd/snaps/blender_1113.snap
214M /var/lib/snapd/snaps/blender_1237.snap
9.1M /var/lib/snapd/snaps/canonical-livepatch_119.snap
9.1M /var/lib/snapd/snaps/canonical-livepatch_126.snap
148M /var/lib/snapd/snaps/chromium_1854.snap
148M /var/lib/snapd/snaps/chromium_1864.snap
17M /var/lib/snapd/snaps/chromium-ffmpeg_23.snap
18M /var/lib/snapd/snaps/chromium-ffmpeg_24.snap
....
~$ ls -lh /var/lib/snapd/snaps/
total 12G
-rw------- 2 root root 31M Aug 5 06:23 2048x_3.snap
-rw------- 2 root root 286M Aug 5 08:35 atom_282.snap
-rw------- 2 root root 4.0K Sep 22 18:17 bare_5.snap
-rw------- 1 root root 72M Oct 30 00:20 bitwarden_58.snap
-rw------- 1 root root 72M Dec 9 04:28 bitwarden_59.snap
-rw------- 1 root root 196M Nov 18 04:06 blender_1113.snap
-rw------- 1 root root 214M Dec 4 09:39 blender_1237.snap
-rw------- 2 root root 9.1M Nov 17 21:06 canonical-livepatch_119.snap
-rw------- 2 root root 9.1M Nov 22 22:39 canonical-livepatch_126.snap
-rw------- 1 root root 148M Dec 16 04:28 chromium_1854.snap
-rw------- 1 root root 148M Jan 8 08:33 chromium_1864.snap
-rw------- 1 root root 17M Sep 3 06:29 chromium-ffmpeg_23.snap
-rw------- 2 root root 18M Nov 29 14:23 chromium-ffmpeg_24.snap
....
On the system that I am looking at, the total disk space utilized by /var/lib/snapd/snaps/*
is 12,180.248 MB. The disk space of all the duplicated packages(i.e. older revision of the same package) is 4,163.1 MB. In short, the older revision packages currently takes up 34.18% of the 12,180.248 MB. This appears to be a cost to using SNAP apps that I had not realised before.
To answer your questions:
Why are they duplicated?
⇢ They're different revisions (versions), not duplications.
Can I remove the older package to ensure better disk space management?
⇢ Yes. It's your computer, after all.
How do I remove the older package?
You can do this in Terminal like this:
You can also tell the system how many past versions to limit itself to like this:
Note: The value must be between
2
and20
, and a number like2
or3
is generally recommended to save storage space and allow a rollback in the event of a bad update.If you would like to list all the snaps and their versions, you can run this command:
Which will give you something like:
Need a Script?
IMPORTANT: You will want to check the output of
snap list --all
on your computer before continuing, and the following is a script that should not be copy/pasted without sanity checking if you are using a locale that is noten_US.UTF-8
.The Script:
This will run
snap list -all
and extract the lines that contain the worddisabled
. This will be different depending on your locale, so check the output of the function first, then updateawk '/disabled/
to replacedisabled
with the label that is found in your output.Save the script to a file (for example
scrub-snaps.sh
) and then set it as being executable:Now you can run it, remembering to use
sudo
:Note:
sudo
was not part of the script, but can be added if you prefer to have it in there. Either way, you'll be prompted for a password if required.Keeping at least one older version of a snap is inherent in the design.
Snap packages were originally designed for a variety of environments where there is often no human admin and/or no way to attach a keyboard and monitor...like phones or IOT devices. Resiliency is a critical requirement for these systems: If an application crashes or an upgrade is corrupted, some form of guaranteed rollback without human intervention is needed. Hence the requirement for at least one older version on-hand.
Folks on classic desktops and servers don't care much about that rollback capability. They like different snap design elements: The secure automatic upgrades that are independent of the OS, the read-only squashfs tamper-prevention, the process confinement, etc.
But it's all a single standard, so you get the rollback capability, too. Even if you think you won't use it.
You cannot "disable" the rollback capability of snaps -- it's not really a "feature" but a key design element.
Building on @matigo answer, I wrote a python script to automate the removal of disabled SNAP packages. It allows a user to visually check the snap packages before proceeding with (or not) the removal process. An example of what the executed script does is shown in the link.
remove_disabled_snap_pkgs.py