Linux distributions are subject to constant change. One of the most recent victims of this constant quest for self-renewal is the classic init system, which most distros have now replaced with systemd.

Another central feature of most Linux distributions is the package management system. The most common package systems are RPM [1], which is used with Red Hat, and Dpkg [2], which is favored by Debian and Ubuntu.

The RPM and Dpkg systems have both benefited from changes and improvements over the past few years, and the idea of completely replacing one of these package management systems with something else has never been seriously considered – until now.

Flatpak [3] and Snap [4] swim in the wake of the container fleets. Both tools envision the package as something like a small Linux system. The package contains all programs and libraries that the application needs, which simplifies the host system, letting it function as a pure container hypervisor. The underlying system still provides a home for containers, but it does not run any programs.

Conventional Packages

No matter how practical RPM and Dpkg may be in everyday life, they regularly cause headaches for software developers and admins.

One problem with conventional package systems is that they are slow – even if the database resides on a fast SSD. In addition, practically every admin will be familiar with the problem of dependency hell. If you use an LTS distribution, but you need a new version of a single program, you cannot simply install the necessary package from the successor distribution. Instead you have to create backports of different libraries and packages and install them collectively.

And, because of the diversity of the Linux platform, if you want to provide a tool for SUSE, Red Hat, Debian, and Ubuntu at the same time, you have to create four individual packages and individually keep them up to date and in line with the distribution release cycle. The complexity of package maintenance is one of the reasons why many developers only release the source code of their programs and hope that the various Linux vendors will independently create a suitable package for it.

Light at the End of the Tunnel?

Flatpak and Snap offer a new approach to the issues that affect RPM and Dpkg. Although these container-inspired solutions officially have nothing to do with Docker, LXC, and other container projects, both solutions rely on the Linux kernel functions that support containers, achieving strict separation of the guest and host using Cgroups [5] and Namespaces [6].

The package formats for Flatpak and Snap come with their own userland. It is not only the programs that reside in this space, but also all the libraries and tools that the program needs to run smoothly.

Flatpak and Snap each deliver their own control program that runs on the physical host and performs a kind of bridge function. Although the programs packaged in Snaps or Flatpaks basically act separately from the rest of the system, they still need access to various host files. For example, they need to parse their own configuration files, which are usually stored in /etc or in the home directory of the executing user. Both Snap and Flatpak therefore define internal interfaces that allow access to external resources.

Exploring Flatpak

Before you get started with Flatpak, it is best to start with a few important terms. First is the runtime, which is not part of a Flatpak but is an external component that Flatpak integrates. The runtime consists of a basic system with the most important files and libraries (Figure 1).

Figure 1: All generic data come from the Runtime – the Flatpak contains only the app and the necessary libraries.

The Sandbox is the container in which the Flatpak app runs. (The developers avoid using the term container because it suggests comparisons with Docker [7] or LXC [8].) The Sandbox is the virtual environment that runs on the hypervisor and where the application is executed.

Bundled libraries are part of the sandbox. The Flatpak often needs libraries that are not part of the Runtime and therefore must be provided separately.

The SDK (Software Development Kit) is also an important element of the Flatpak ecosystem. The SDK is similar to the runtime but also contains the development files. In other words, the developer builds the Flatpak against a certain SDK version, and this Flatpak then runs reliably with the runtime associated with the SDK.

To get started with Flatpak, check whether the package is available through your current package manager. Arch Linux and Fedora include a Flatpak package out the box. Debian Testing comes with a flatpak package, and a backport for Debian Jessie is also available [9]. Packages from the manufacturer are also available for OpenSUSE Tumbleweed [10].

If you use Ubuntu, you'll find the packages in a PPA by the main Flatpak author on Ubuntu's Launchpad code platform, and you can install them with the following three commands:

sudo add-apt-repository ppa:alexlarsson/flatpak
sudo apt update
sudo apt install flatpak