Recently there has been a movement within the Linux community towards so-called universal packages. The problem with traditional packaging, according to this movement, is that it is too distribution-specific. For example, Debian and Fedora use different package formats (DEB and RPM), so a given application must be separately packaged to accommodate both. Wouldn’t it be easier if all distributions therefore used a common package format?
How Many Boxes of Salt Do You Need?
Package management is one of the core functions of a Linux distribution. Imagine you want to make chicken parmesan. You need to go to the store and buy the necessary ingredients: chicken, tomatoes, cheese, et cetera. The package manager serves as your personal shopper who gathers all of the ingredients you need to make the dish–and then cooks the food to boot!
In package management, the ingredients are known as dependencies–i.e., Package A requires Library B to function. The package manager makes sure all of the required dependencies are met before installing the package. The distribution’s maintainers also build each package to work in a certain combination. In other words, if multiple applications require Library B, the maintainers make sure there is a single version of that library that meets each package’s needs, so it’s not necessary to have multiple (and potentially conflicting) versions of the same library.
Supporters of “universal” packages argue this gives too much power to the distribution maintainers and prevents application developers from quickly getting the newest versions of their software to users. The idea behind these new packaging methods is to bypass the distributions altogether. There are a number of ways to do this, but the common principle is that the user downloads a single package or file that includes all of the dependencies, regardless of whether or not said dependency is already installed on the operating system. Since these “universal” packages function independently of the operating system, it is unnecessary to worry about ensuring uniformity among system libraries.
To return to the grocery metaphor, suppose you want to make three different recipes. There are some basic ingredients common to all of the dishes, such as salt. Under traditional package management, you would buy one box of salt and share it among all three recipes. But with “universal” package management, you would buy three separate boxes of salt, one for each recipe.
Obviously, buying and storing that much salt would be wasteful. Similarly, distribution-independent packaging requires more storage space than traditional package management, as you are likely to end up with multiple copies of the same libraries. Supporters claim this isn’t a problem because modern hard drives offer more than enough capacity.
Are Any of These the Future of Linux Applications?
So how do these new package formats work in practice? I recently tried three of the more highly publicized options: Snaps, AppImage, and Flatpak. To be honest, I don’t see any of them replacing the traditional distribution-based package managers that I currently use. And I think all three raise red flags for users who actually care about the quality of their computing experience.
Snaps are a package format sponsored by Canonical Ltd., the developers of Ubuntu. Users of Ubuntu 16.04 should have the snapd package already installed, which allows the user to install snaps from the command line. It’s not much different that installing packages using traditional DEB packages. Instead of typing:
sudo apt install package
the user enters:
sudo snap install package
The snap is a self-contained application that includes all required dependencies. According to Canonical, “Snaps are updated automatically in the background every day.” At the moment, snaps are only available from a Canonical-based store, although the company says “we expect people will have different stores for their snaps in future.”
The Ubuntu tutorial for snaps recommends installing a basic “Hello World!” program. The download size was nearly 75 MB, which is quite a lot for a program that does nothing besides display a simple greeting message. But this is a common thing with snaps and similar formats–they are significantly larger than traditional packages. For example, if you install LibreOffice via a snap, the download is 347.45 MB, nearly three times the size of the DEB package in the regular Ubuntu repositories.
Besides the pointless “Hello, World!” program, I installed one snap for an application I actually use, the IRC client HexChat. It installed and ran fine, no better or worse than a normal DEB package. But it’s worth pointing out there aren’t many practical snap packages available at the moment. Even LibreOffice is only available from a “beta” release channel and is not considered “stable.”
AppImage is perhaps the most aggressively marketed of the new package formats. The project’s website touts an endorsement from Linux kernel creator Linus Torvalds, and the documentation reads like a paranoid rant against the supposed evils of distribution maintainers. According to AppImage, the typical user wants to “download an application from the original author, and run it on my Linux desktop system just like I would do with a Windows or Mac application.”
In that sense, AppImage delivers what it promises. The user downloads an AppImage file and runs this command to make it a self-contained executable program:
chmod a+x package
I tried a couple of AppImage files and they worked perfectly well. There are certainly more AppImages available than Snaps, and I found a number of programs that I regularly use were available. For instance I installed Calibre, an excellent tool for managing e-book collections. Of course, despite AppImage’s claims that it can deliver the most recent versions of software–again, by eliminating those filthy distribution middlemen–the Calibre AppImage was a few revisions behind the most recent release. But to be fair, Calibre tends to update a lot more than many other applications. And as with Snaps, AppImage files are larger: Calibre was twice the size of its DEB counterpart.
Finally, I tried Flatpak, which is backed by enterprise Linux giant Red Hat, Inc. Flatpak is certainly the most complicated of the three “universal” formats I tried. First, I had to add a separate archive to the existing package manager to download the Flatpak program (I ran all of these tests in Ubuntu 16.04, incidentally). Then I had to install a runtime, which contained all of the dependencies. And only then could I install actual applications.
I followed the instructions for installing GNOME applications via Flatpak. This required downloading a 171.7 MB runtime of GNOME dependencies. Then I tried installing two GNOME applications, Maps and Rhythmbox. Both appeared to download and install without incident.
And then I tried to run them. Nothing happened. When I tried again from the command line I got this message back:
error: runtime/org.gnome.Platform/x86_64/3.22 not installed # App failed to start
Per Flatpak’s instructions, I installed the GNOME 3.20 runtime. But Flatpak is looking for the more recent 3.22 runtime. That would require another 179 MB download. At that point I just gave up.
Are AppImages a Threat to Open Source?
Beyond the question of how well each of these new packaging systems worked, I have concerns over how they compromise the user’s control over the system. Flatpak and AppImage do not require super-user privileges to install. This means anyone who gains access to my computer could install software without my consent.
Canonical also highlights the fact Snaps update automatically. I’m not a fan of this. One of the major problems many people have with Windows is the forced upgrades that can disrupt a system. I prefer to control when and how I upgrade software. Even one the AppImages that I installed displayed a message on the first run asking if I wanted to allow or disable automatic upgrades by default.
I also see distribution-independent packaging, particularly AppImage, as a potential end-run around traditional open source licensing. Distribution maintainers do more than package software; they also ensure that all included software complies with the GPL and similar licenses designed to protect user freedom. But if a developer can simply release an AppImage, there’s no need to use an open source license. And in fact, some projects like Aseprite have altered their licensing in exactly that way. Aseprite allows users to download an AppImage (or compile the source code themselves), but Linux distributions are legally blocked from integrating the application into their own package managers.
Snaps, AppImage, or Flatpak? Try Solus Instead
Snaps, AppImage, and Flatpak all tout themselves as the “future” of Linux applications. Well, they’re sure not the present. None of them make much sense to me as a Linux user, especially Flatpak.
AppImage is the only one I might consider using in the future, but even then it would have to be a case where I somehow required a more recent version of software than I could get from a distribution. And honestly, I can’t recall the last time I faced that situation.
If having the most recent applications is a priority for you, I would advise using Solus as your Linux operating system before trying any of the “universal” packaging voodoo discussed above. Solus, which uses its own in-house package manager, has already proven it is possible to get the most recent software out without gimmicks. Indeed, just this past week Solus managed to distribute the latest version of Firefox to its users even before the web browser was officially released by Mozilla.