The race for a universal package manager
Package Deal
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).
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
.
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
(incl. VAT)
Buy Linux Magazine
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.
News
-
Canonical Releases Ubuntu 24.04
After a brief pause because of the XZ vulnerability, Ubuntu 24.04 is now available for install.
-
Linux Servers Targeted by Akira Ransomware
A group of bad actors who have already extorted $42 million have their sights set on the Linux platform.
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.
-
Linux Usage Increases in Two Key Areas
If market share is your thing, you'll be happy to know that Linux is on the rise in two areas that, if they keep climbing, could have serious meaning for Linux's future.
-
Vulnerability Discovered in xz Libraries
An urgent alert for Fedora 40 has been posted and users should pay attention.
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.