I hate to write a question like this [1], but I want to remove cups completely and permanently. I don’t need it, and I don’t want it (and it has attack surface that I really don’t want).
I snap remove cups but whenever I upgrade some other snap (firefox? thunderbird?) then cups gets silently reinstalled. There’s no indication that snap refresh is reinstalling it.
I tried snap remove cups; snap refresh –hold=forever cups as suggested by some AI, but it still gets reinstalled.
How do I block cups from ever being installed?
Thanks,
Bruce
[1] I have been using FOSS for over 25 years and I massively appreciate the hard work put in by generous maintainers. It really annoys me when people are disrespectful to this freely given time, effort and love: I hate it when users say that they “hate” some free software or other. I have nothing against the cups project, or its maintainers, I just don’t need this software on my systems and I want the freedom to remove it.
There’s perhaps 2 options that might help you here.
Option 1 is just keep the CUPS snap installed but have it disabled, it’ll consume disk space but be functionally inert, you can do that by running sudo snap disable cups
Option 2 is to find the package that’s triggering the installation automatically.
In the future, it’s possible that the presence of the cups interface alone would be the trigger for the CUPS snap to download, but as of right now, it’ll be being included by slightly abusing a content interface instead.
snap connections | grep content\\[ | grep cups:
I can’t conveniently find a snap that installs CUPS automatically on my end; it’s certainly not Firefox/Thunderbird however. But using the Gnome content snap as an example:
Above would show that Firefox has a plug called gnome-46-2404, so we’d unplug it with e.g., sudo snap disconnect firefox:gnome-46-2404 (the second item in the row)
Replace that with whatever snaps are pulling CUPS and then remove CUPS itself, and it might stop coming back when they update as the disconnect is remembered during upgrades.
And of course, please don’t disconnect Firefox from Gnome
plugs:
# This is not used or needed for anything other than to trigger automatic
# installation of the cups snap via "default-provider: cups"
install-cups-runtime-dependency:
interface: content
content: foo
default-provider: cups
target: $SNAP_DATA/foo
There’s no robust way of avoiding this without changes in snapd.
The easiest way would be to create your own empty “dummy snap” which provides the relevant slot and remove the cups snap; based on how snapd handles content interface prerequisites, your snap should satisfy chromium’s dependency and evade having cups present on the system. It would result in a few hundred kilobytes of dead space.
It’s a good option, I was reserved with suggesting it because I was concerned how the connections work with it being partially based on the assertions for the content side, still I gave it a go:
FWIW even keeping an explicit cups slot, snapd didn’t autoconnect, so I think that must also be part of the assertion and there’s functionally no difference in not having it at all then in this case.
(Constrain the read attribute of your slot accordingly if you don’t want to expose all of your snap as read-only to arbitrary consumers).
The plug/slot won’t auto-connect because, in terms of content interfaces and published snaps, that auto-connection can only happen if you’re the publisher of the snaps on both sides (sauce).
In terms of declaration assertions, I don’t believe it should have any meaningful impact here (there doesn’t appear to be anything special with respect to this topic in the chromium snap declaration assertion). Really what chromium is doing is taking advantage of a snapd feature where, if nothing provides the relevant slot, the default-provider will be fetched (even if it itself does not provide such a slot) (sauce).
Importantly, your content type attribute must match the content type attribute declared by the chromium snap (in this case, foo).
You shouldn’t need to connect the interface (nothing would break if you did), as snapd merely checks that the connection could be satisfied by the current state of the system, not that it is.
Hiya - just to be clear, I agree with what you say right until the end (that snapd checks it could be satisfied; in my case it can’t be satisfied, but it doesn’t matter)
The content interface is exactly as you describe with the publisher names not matching, but the content interface only exists to trigger the install as you say.
The autoconnection on cups itself however could effectively be either snapd base policy, or an assertion. As it is right now, it’s part of the CUPS assertion, which I’m only really mentioning cos I’m too verbose
Since we don’t have an assertion being a dummy snap, there’s nothing really gained to define a CUPS slot in the dummy’s YAML, because the (auto)connection is never attempted when other snaps are installed, meaning we can keep the dummy itself extremely minimal being nothing more really than declaring its own name
Ultimately, it absolutely should work for OP if they’re happy to have a 4KB snap installed and it still appearing in the list of snaps; which is still better than snap disable, the above dummy allows Chromium to install just fine.
