The race for a universal package manager

Package Deal

Article from Issue 190/2016
Author(s):

We look at four contenders that want to become the Linux universal package manager, although the reality is still on the horizon.

So far, 2016 is likely to be remembered as the year in which universal package managers were debated. With the announcement of Ubuntu's Snappy packages, followed quickly by Fedora's and Red Hat's release of its Flatpak format, the race is on for a method of software installation that will work on any distribution and make .deb, .rpm, and the rest footnotes in Linux history.

Advocates of a universal package manager claim that it will make software installation more efficient by eliminating dependency problems. Additionally, many candidates include extra security and extra features, such as package installation by ordinary users for their own use. However, whether any improvements will result is questionable. Debian developers in particular insist the way to eliminate software installation problems lies in enforcing a strict package structure, as described in the Debian Policy Manual [1].

In fact, Josh Triplett, a long-time Debian contributor, went so far as to suggest that Debian's reputation is a consequence of the Debian Policy, and not the .deb format. According to Triplett, "Debian without the .deb format would still be Debian; Debian without [the] Debian Policy would just be Sourceforge or Rpmfind," and nothing more than a random collection of software [2].

This claim is borne out by the specialized installers available for some programming languages, which configure aspects of the language, but not external dependencies. A new format would not eliminate such problems, but more detailed package guidelines might.

Besides, as many observers point out, the attempt to establish a universal standard in free software tends simply to add to the number of choices. Perhaps Flatpak and Snappy will simply replace DEBs and RPMs as the two main rivals in package management.

Still, whether a universal package manager is needed or not, the fact that two candidates are backed by corporate interests means that attempts to establish one as the Linux standard are likely to continue. Here are the four candidates most often mentioned:

AppImage

Under various names, including klik and PortableLinuxApps, AppImage has existed since 2004 [3]. No application is needed to manage AppImage packages, and each packaged application and its dependencies are stored in a single file. Running an AppImage package requires only changing permissions to make it executable, then deciding whether to add a desktop launch the first time you click the package (Figure 1).

Figure 1: AppImage offers to create a launcher the first time one of its packages is run.

Historically minded people mention AppImage as a possible option for a universal package manager, but the possibility seems remote, even though a number of applications, including Audacity, Blender, and Krita offer AppImages [4].

For one thing, the single static file takes far more space than a standard .deb or .rpm file. For example, the sample on the project's home page for SubSurface, a diving diary favored by Linus Torvalds, requires seven and a half times the memory of the same .deb package. This difference might not matter on a modern system but probably makes AppImage unsuitable for an older machine.

More importantly, AppImage is not designed with security in mind. Even the project's homepage suggests that AppImage is best suited for installation from upstream sources – which means, among other things, a trusted source. Users can use permissions to limit who can run an AppImage package, but security goes no further. Other security modifications would be necessary to make AppImage a suitable candidate.

Flatpak

Flatpak [5] development is led by Red Hat developer Alexander Larsson. It uses the same basic command for building and managing packages, as well as enabling repositories, differing only in the options available for each task. Perhaps because Flatpak has the examples of other package managers to draw upon, instead of being developed from scratch, it has some of the clearest and most consistent names for options and commands ever to find their way into a man page. In particular, unlike DEBs, Flatpak provides separate commands for installing and updating, instead of giving them the same name.

Packages for Flatpak are sandboxed by having separate run-time environments and by using standard Linux tools such as cgroups [6] and namespaces [7] to assign resources to each package and isolate them from each other. Because these tools are standard in recent kernels, they do not significantly add to the size of packages, especially because Flatpak can use already installed dependencies as well as new ones.

Additionally, each version of each Flatpak is a separate branch in the Git-like repository OSTree [8]. This arrangement makes it easy for different releases of the same application to co-exist on the same system, and for packages to be rolled back and deleted cleanly. The use of OSTree also gives Flatpak additional levels of security, with checksums for each individual file and for checking out branches that are in use.

Moreover, using OSTree also has the advantage of making packages editable with the ostree command. Some overlap with Flatpak commands results, but ostree also has a number of advanced tools, such as administrative cleanup and built-in diff. Users can ignore ostree and most likely get along fine much of the time, but learning the command might come in handy at times.

The disadvantage of using OSTree is that only one branch (i.e., software version) can be active at one time. That means that system upgrades do not go into effect until after a reboot.

Flatpak runs on many major distributions, but, as I write, few packages or repositories are available. Probably the best tool for exploring Flatpak is the LibreOffice package, whose download page also details clearly how to set up a repository [9]. Should your system segfault (i.e., trigger a memory access violation) in the process, try again with the most recent kernel you can find.

Guix

Guix [10] is a member of the GNU Project, the software collective associated with the Free Software Foundation (FSF). In fact, early in 2016, Guix became the first package manager to be ported to GNU/Hurd, the long-awaited alternative to the Linux kernel [11].

Guix is also the package manager for the GuixSD distribution [12], although it can run on any distribution, even alongside another project manager. It is not available as a package itself, but its installation, while not graphical, is still relatively easy to use with the instructions.

Guix (Figure 2) is based on an older package manager called Nix [13]. The two parted company several years ago, and today Guix is written in GNU Guile, while Nix uses a variety of programming language. What both have in common is the metaphor of package management as a mathematical function that is affected by scripts and other inputs but cannot itself alter the system environment or edit files outside of its own directories beneath /gnu/store.

Figure 2: Output of Guix while installing a package.

This arrangement has numerous advantages. Unlike with a .deb package, a Guix package cannot be half-installed; either it is completely installed, a feature that makes a rollback to an early version of a piece of software much easier, or it is not installed at all. The isolation of packages means that ordinary users can install software for their own use that does not challenge security, because each package is isolated from the others. Most importantly, package isolation creates a level of security comparable to that of a container without the extra overhead.

From a technical perspective, these features make Guix a serious competitor to Flatpak and Snappy. If it lacks a corporate backer, the FSF may be a suitable substitute, especially because its main interest is to keep the core parts of an operating system available as a free license.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

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.

  • 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.

  • Introduction

    This month in Linux Voice.

  • bauh

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

  • Systemd Flatpak Updates

    You can automate Flatpak updates without a package manager using systemd's services and timers.

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