There aren’t large dependency graphs for snap packages the same as you’d see for .deb or .rpm packages. At present, there are two cases where installing a snap package will trigger the installation of another snap:
- If the snap’s base snap is not present on the system. A base snap provides the root file system image used to run the application in. At present, there are three commonly used base snaps (
core20), so it is rare for these to be missing.
- If the snap has a content interface plug and the snap with the matching plug is not installed. The main places you’ll see the content interface used today is to share groups of libraries (such as
gnome-3-34-1804), or common data files (e.g.
There isn’t currently an obvious way to determine what snaps might be referenced here without first downloading the snap. However, this blog post describes a way to request the
snap.yaml metadata for an arbitrary snap via the store API:
After issuing that curl command, you want to look for the following:
- The value of the
base: property at the top level gives the name of the base snap.
- In the
plugs: section, look for subsections that set
interface: content. The
default-provider: property lists the name of the default snap providing that data.
It probably wouldn’t be too difficult to put together a script that pulled this information together for a given snap, and filtered out the deps that are already installed.