Universal Package Formats and How They Differ

Flatpak and Snap

By

We talk with Alexander Larsson, the creator of Flatpak, and Thibaut Rouffineau, a member of the Snap team.

The Flatpak and Snap packages are often discussed together. The tendency is only natural, because both are attempts at universal packages – that is, packages meant to run on any Linux distribution. To accomplish this goal, Flatpak and Snap use comparable commands, and both bundle their own dependencies, rather than relying on those already installed. Both, too, can install in containers. Yet, despite these similarities, their rationales and purposes are not the same, as I found out in discussions with Alexander Larsson, the original creator of Flatpak, and Thibaut Rouffineau, Canonical’s head of Internet of Things marketing and part of the team developing Snap.

To start, Larsson’s and Rouffineau’s critiques of existing package management systems differ in emphasis. For Larsson, the problems of traditional systems like .deb and .rpm are mostly for the developers. He describes these traditional systems as “an excellent way to construct an operating system. You can split the whole into individually maintainable modules and describe dependencies to get a minimal installation based on requirements.” However, for Larsson, their main problem is that the resulting systems are not always consistent. Packages, he says, are not installed in a consistent order, and “this means that each client system is unique, and never matches the one that the developer tests.”

Rouffineau also mentions problems for developers. For instance, Rouffineau notes that while .deb or .rpm packages are easy to build, “the distro requirements for getting them into an official repository are much more strict and complicated, which can delay the availability of upgrades, especially for distributions with a stable release. Moreover, “every distro is different, has different dependencies, and uses different tools,” so that, effectively, developers are forever “putting out new packages for every new distro release.”

Additionally, Rouffineau sees problems for users, such as the possibility of broken dependencies and outdated packages. He expresses concerns, too, about giving untrusted archives too much access to a system and that “many pieces of software users want are not and never will be packaged for a distro.”

These two analyses of the current state of package management lead Larsson and Rouffineau to somewhat different conclusions. “The main reason for creating Flatpak is not due to technical problems with package management formats,” Larsson explains, so much as the chance to take advantage of recent kernel features and that the increased use of images to deliver software – particularly with containers – “makes something like Flatpak, where the applications are not part of the operating system, more important.”

By contrast, Rouffineau says that “Linux users are increasingly expecting more of a consumer experience for applications – much like the app experience on a cell phone, for example. This is true not only on the desktop, but also on servers, where anyone can use Ubuntu on Amazon Web Services, for example, and get a server started without being a sys admin or DevOps professional. We see a demand for Rocket.Chat [a private chat system] as a snap, for example.” Similarly, “Internet of Things vendors have realized that they need more ways to operationalize their deployments, as software is becoming more important than hardware.”

Universal Advantages

Both Flatpak and Snap are still in development, and so far, many of their advantages are more potential than fully realized. All the same, armed with these two analyses, Rouffineau and Larsson emphasize different advantages for their versions of universal packages.

On the one hand, according to Rouffineau, Snap packages are simply easier to prepare. “Snaps are fundamentally just a directory with a metadata file that gets SquashFSed” – that is, delivered in a read-only archive. “As snaps include their dependencies, it doesn’t matter what will be available on the user’s distro or what version they have. There are also no concerns about whether it will be removed.” With these advantages, snaps can potentially ensure that applications are always installed correctly and identically.

For developers, Rouffineau sees Snap as offering a single, centralized store for all distributions. Such a centralized store can offer “more data about the user base, such as location and which version is used.”

On the other hand, Larsson’s emphasis is largely on the development process. Like Rouffineau, Larsson mentions easier distribution across all distros, but, for him, the main advantages lie elsewhere.

For Larsson, one of the main advantages of Flatpak is its ability to sandbox applications. “The traditional Unix security model is to protect users against each other and, in particular, normal users from root,” he notes. “[But] this is not really protecting the important things. If an application in my desktop is exploited, it has full access to all the things my user has, which means it can read all my documents and mail, impersonate me on Twitter and Facebook, and send spam in my name. Having a way to have separate security domains in a single desktop makes it possible to protect against this in a much better way.”

However, Larsson points out that sandboxing is an optional feature, and the level of security can be varied. Also, “few Linux apps are possible to fully contain at this moment – although games can be pretty contained.”

Another advantage that Larsson emphasizes is the chance for upstream developers to become more involved with their users. With traditional package management systems, a distribution’s maintainers intervene between upstream developers and users. However, with Flatpak, in theory, “the upstream developer can release directly to the end user, then get immediate feedback. Users immediately get new features and can report issues against what the developers are actually working on rather than reporting bugs that have been fixed long ago or requesting features that are already there. Hopefully, a shorter feedback cycle like this will allow the community to work better, the software development iterations to become faster, and the end result [to be] better.”

The Future of Package Management

Neither Rouffineau nor Larsson expect their versions of universal packages to replace traditional systems like .debs. or .rpm. Rather, they see universal and traditional packages as co-existing.

According to Rouffineau, “.deb packages offer flexibility, while Snaps offer ease of use. Different scenarios may dictate and determine which is used. For example, conventional package managers are the best solution for building operating systems, where a small group of people are managing a large number of interconnected packages.”

“On the other hand,” Rouffineau continues, “Snaps are a better solution for distributing independent, standalone applications – whether that be on desktops or headless servers/devices – that run on top of an operating system and don’t require changes to release co-ordination with operating system packages. Snaps were developed from the outset to support a wider range of use cases across the spectrum from the desktop to cloud and Internet of Things devices.”

Similarly, in Larsson’s opinion, “Flatpak is really only for desktop applications and is not a good fit for the core operating system itself. My hope is that the separation of applications from the core operating system leads to a model where the distributions can focus on improving the core, rather than competing in how many different applications they can package.” Using Flatpak, Larsson suggests, would mean that “there is less incentive to pick a distribution based on whether it has your favourite application packaged, but rather on the quality and feel of the operating system itself.” In effect, Flatpak “allows you to install applications as a separate entity from the operating system image.”

What the Future May Bring

Both Flatpak and Snap are being marketed as the future of Linux package management. However, in many ways, their similarities have more to do with their relation to traditional package systems than with each other.

Yet such marketing conceals technical differences. For instance, Flatpak uses kernel namespaces to create a custom view of the system for each app, so that each application has its own view of the /usr directory. Snap, though, installs each package in a separate directory, then configures AppArmor to limit the package’s access to directories. As well, Snaps rely on Ubuntu Core, whereas Flatpak is less focused on any particular distribution – although it tends to be associated with Red Hat for the simple reason that Fedora has been one of the main distributions to implement it.

However, from a user perspective, the difference is one of emphasis and direction. Larsson’s vision is focused on the desktop and anticipates new relations between users, maintainers, and upstream developers. By comparison, Snap seems more ambitious, with Rouffineau envisioning it encompassing both the traditional desktop and the rapidly developing cloud and Internet of Things markets.

How practical either of these visions actually is remains to be proved. As openSUSE Chairman Richard Brown points out in a presentation at the 2017 FOSDEM conference, whether the community of developers is prepared to accept these new relationships is uncertain. Traditionally, upstream developers have paid little attention to packaging and legal issues, and it is not at all certain that, without something like the Linux Standards Base being widely used, the differences between distributions may be too great for any form of universal packages to become widely used.

Unless upstream developers are prepared to undertake the traditional responsibilities of distro maintainers, the hopes for better user feedback and the quicker delivery of packages may never be fully realized. Although distributions like openSUSE are already experimenting with offering versions with universal packages, in the end, conventional packages may be used primarily for the desktop, and universal packages for delivering images to containers and embedded devices.

Of course, the roles of Flatpak and Snap alike are still being determined. In the end, understanding the differences between the two universal formats may be as important as understanding how they both differ from conventional formats.

Related content

  • Universal Package Systems

    Billed as the future of package management, universal package systems like Snappy and Flatpak have failed to live up to their promise.

  • Ubuntu No Longer Shipping with Flatpak

    In a move that probably won’t come as a shock to many, Ubuntu and all of its official spins will no longer ship with Flatpak installed.

  • Flatpak and Snap

    The new container-inspired package formats Flatpak and Snap have landed in the territory occupied by conventional Linux package systems such as RPM and Dpkg.

  • Parcel Service

    The traditional package management systems on Linux are now somewhat outdated, but AppImage, Flatpak, and Snap see some interesting new management systems enter the fray.

  • bauh

    The bauh package manager can cope with Flatpaks, Snaps, AppImages, AUR, and native web apps.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More

News