Snappy

Snappy packages (Figure 3) got off to a rocky start when Canonical Software, which controls Ubuntu, announced them as though they had already become the universal package manager. A typical headline in the media was "Snap Packages Become Universal Binary Format for All GNU/Linux Distributions" [14], when the truth was less dramatic.

Figure 3: Using the snap command to install FreeCAD.

Originally developed for embedded systems, Snappy's packages, like AppImage's, are reminiscent of the static tarballs used in the 1990s, combining all libraries, programs, and scripts in a single file. The main difference from static tarballs is that .snap packages add containers and draw on recent Linux features for an added level of security.

Shortly after Snappy was announced, the rumor went around that its packages were as bloated as AppImage's. The source of the rumor was a LibreOffice snappy package whose debugging tools made it appear 500% larger than the equivalent .deb or .rpm when the truth was closer to 20%. Still, even a 20% difference in size can be significant on busy systems, or older ones.

Even more seriously, while Snappy, Flatpak, and Guix all offer similar features – everything from extra security to rollbacks and the co-existence of multiple versions of the same application – Flatpak and Guix do so with less overhead. True, Snappy packages can be built without containers in developer builds by using the --devmode option, yet that only creates a new danger. Although Snappy documentation insists that packages built with --devmode will never be included in official repositories, it is easy to imagine users preferring unofficial repositories to save memory – and, in doing so, removing a major part of Snappy security. Such a practice is more unlikely in Flatpak or Guix, whose security is architectural and probably more difficult to bypass.

Some users, too, might balk at a universal package manager being developed largely inside Canonical and under a contributors' agreement that gives Canonical almost complete ownership of any software that is produced [15].

However, Canonical remains one of the most influential Linux-based companies. Already, there seems to be more software available in .snap packages than in any of the other formats, so Canonical might win the competition through publicity and availability alone.

Waiting for the Endgame

Universal package managers still have a ways to go. As I write, for example, graphical versions of Flatpak, Guix, and Snappy have yet to appear, although they are a high priority. In places, too, although basic functionality is available, there is still plenty of room for enhancements. As Fedora's replacement of yum with dnf shows, adjustments to package management can be more difficult than many expect [16].

In the end, which candidate becomes universal – if any – is unlikely to be decided for several years. Possibly, while the competition fuels the commercial rivalry between Canonical and Red Hat, few distributions will see the need for a universal package manger, all the more so because the conversion to a new format would be a major effort.

Moreover, although the .deb and .rpm rivalry can sometimes be a nuisance, it is at least a known nuisance. And whereas DEBs had an advantage around the turn of the millennium, RPMs have been roughly functionally equivalent for more than a dozen years.

Under these circumstances, we can expect a lot of discussion and little resolution. Unless some statement or new feature highlights the issues involved, I expect the situation to remain much the same.