YAML Files

Like Flatpak, Snap offers the ability to create a package based on a JSON file, but YAML format is standard. You can define keywords and paragraphs in the YAML file and then feed the file to Snapcraft [14], which builds a complete Snap from the information.

Snap comes with the GNU Autotools plugin, which you can use for building a program from the source code. You can use the built-in plugin interface to include functions that are missing in the Snap core. The Autotools plugin ensures that the familiar three-step process, ./configure, make, and make install works when you convert source code to binary code.

The keywords, name, version, and summary let the snap creator define the name of the snap, the version number, and the summary it will report. The confinement keyword is particularly important: options include strict (the default option) or devmode. strict strictly isolates the Snap from the rest of the system. For production snaps, confinement: strict is more or less mandatory. A ready-to-use YAML file for a Hello World snap would look like Listing 2.

If you are building snaps of more complex programs, you need to expand the parts section. If the program requires dependencies in the form of libraries, enter them in the appropriate order in the YAML file.

To build the snap, store the YAML file as snapcraft.yaml and run the snapcraft command within the directory. (Be sure the snapcraft package is installed on the system.) On Ubuntu systems, you will find snapcraft in the official archive; for other distributions, see the instructions online [15]. Snapcraft is available for both Fedora and OpenSUSE.

Following the Snapcraft call, find a file with a .snap file suffix in the working directory. To run the snap on a system, the system needs the Snap daemon, snapd. Once snapd is running, you can install the snap:

sudo snap install *.snap --dangerous

Concerned readers might be a little worried about the --dangerous parameter. Don't panic! The parameter just tells Snap to skip the built-in signature validation, which ensures that only snaps from sources that the admin explicitly trusts are installed on the system.

The example shown here only scratches the surface of what is possible with Snap. The very detailed documentation, which sheds light on the possibilities and options, is available on the program website [16].

Interface System

A container app that is completely isolated from the rest of the system is of limited use. To integrate itself with the normal workflow, a container app must at least be able to access a user's personal directory. Snap solves this problem by offering standardized interfaces for different types of services [17].

For example, the home interface gives a snap access to user folders. The dbus interface allows access to the D-Bus on the host system. Some of the interfaces have more exotic capabilities: For example, the camera interface lets a snap access a connected camera; tpm lets the snap control a Trusted Platform Module (TPM) for cryptographic functions.

The Snap developers have also put some thought into the way snaps communicate with each other. An application that provides a service, can define a slot in its YAML definition – say, a MySQL database. Another snap can define a Plug, which then connects to the previously defined slot (Figure 4).

Figure 4: Communication between Snaps relies on plugs and slots, which are specified in the YAML definition.

The Big Difference: A Ready-Made Online Repository

The most striking difference between Flatpak and Snap is that Canonical is already running an online marketplace for ready-made snaps (Figure 5) [18]. The store offers snaps that administrators and developers have built for different use cases.

Figure 5: The Snap Store already contains various ready-made snaps that users can install at the click of a mouse.

All snaps that end up in the Canonical Snap Store are digitally signed – users can therefore be sure that they are picking up the snaps from a safe source. (Flatpak is reportedly working on a similar feature.)