Prevent snapd from ever being installed again

[rany2]

Adding the following apt config would prevent snapd from being installed either directly or indirectly:

Package: snapd
Pin: release a=*
Pin-Priority: -10

Linux Mint already does something similar. This is important because Ubuntu made the Chromium apt package install snapd and install the Snap version of Chromium.

[popey]

Thanks for filing this issue.
I was thinking about this when I was adding support for Linux Mint and to test I had to undo this feature to install snapd.
I'll certainly have a think about this. if done, we'd need to do it in a distro agnostic way, I guess. Although (currently) it's only really Ubuntu derived systems which have the risk of a deb magically installing a snap.

Will give it some thought. Thanks again.

[rany2]

Not the most elegant but you could use something like this to detect if a pin for snapd already exists: LC_ALL=C apt-cache policy -q | awk 'BEGIN {seen = 0} /^Pinned packages:/ {seen+=1} {if (seen==1) {seen +=1}else if (seen > 1){print $1}}' | grep -q ^snapd$

[ghost]

Would sudo apt-mark hold snapd work instead?

[rany2]

@BWPanda According to the manual page, apt-mark hold also prevents autoinstallation; so yes.

[than3-bits]

I'm interested in a solution for this as well.

I had found that a number of packages in the apt repository hosted by Canonical, are in fact not the software being advertised but instead contain a fixup script that non-interactively installs snapd if its not present; or disabled; and its related dependencies first and then installs the snap for the software second without prompt.

apt has no visibility on these type of packages so it pretty much kaiboshed any further use of the OS for my uses in a production environment. As its a non-deterministic problem, I can't really work around it (i.e. apt can't differentiate between the binaries that are software and the binaries that are fixups; so fails determinism test with same inputs different outputs), and the problem originates on servers you don't control.

Professionally, I can't have an apt upgrade issued by a tech break written security policy with no visibility on their end. I'm not sure there is a good solution to this short of maintaining a separate repo you can control. I like Ubuntu derivatives but recent changes have become problematic. I had a little bit of hope when I saw this project as flatpack does meet our security standards.

Firefox was the main package I noticed which did this, but there were a few others.