When Canonical Software, the company behind Ubuntu Linux, announced that developers from other distributions were working on Snappy packages, the media pumped a minor announcement into a major story.
The headlines alone tell the story: "Snap! Ubuntu 16.04 Just Made Installing New Apps MUCH Easier;" "Goodbye apt and yum? Ubuntu’s snap apps are coming to distros everywhere;" "Snap Packages Become Universal Binary Format for All GNU/Linux Distributions;" and "Ubuntu bids to eliminate Linux fragmentation by making Snap packages available to all."
If this story were true, the headlines would have been announcing the most important news in Linux for several years. However, like much that seems too good to be true, the news was.
Snappy packages are a throwback to the static tarballs of the 1970s, bundling all the necessary dependencies for a piece of software in a single package and running from a container for added security. Originally intended for embedded systems, Snappy had in recent months been developed as a simpler method for installing desktop software as well. These efforts had attracted the contributions of developers from distributions other than Ubuntu, and Canonical was announcing that the Snappy format now ran on many major distributions and could be easily ported to others.
Unfortunately, even this simple story became distorted in the media. While other distributions were interested in Snappy, none have actually announced yet that they will use the format. In particular, the Canonical statement implied the involvement of Fedora with Snappy, provoking the comment from Fedora contributor Michael Catanzaro that Fedora is developing a competing solution called Flatpak, and that Fedora developers "have zero plans to adopt Snappy in Fedora."
Ubuntu Core Engineering Manager Jamie Bennett further muddied the waters by blogging that "Distributing applications on Linux is not always easy. You have different packaging formats, base systems, available libraries, and distribution release cadences all of which contribute to the headache." In the same blog, Bennett also claimed in some depths that snap packages are more secure.
The news seems to have come as some surprise to many, especially those who work with the .deb format regularly, who have always prided themselves on the quality of their packages. For instance, former Debian Project Leader Branden Robinson remarked, "It's pretty cheeky of Canonical to spend ten years building itself on the foundation of reliability that Debian provides, and then denigrate the processes, technology and personal discipline that sustain that foundation."
Amid all these conflicting statements, how are non-experts to know where the truth lies? In the interest of saving space, one way is to judge both the pros and cons of Snappy packages in the hopes of reaching a few less sensational conclusions.
1. Snappy packages mean less work for developers.
True. Currently, developers must either settle on a single package format, which inconveniences users, or else maintain packages for at least 32- and 64-bit .deb and .rpm formats.
2. Snaps are easier to build.
Questionable. Compare the instructions for building snap packages with the instructions for building .deb packages. Both are documented step by step, but each has its own jargon and only gets easier with practice. Neither is for beginners.
3. Snap packages remove dependency problems.
Debian developer Marco d'Itri speculates that this claim is made because an increasing number of technologies like node.js require a specific version of libraries. However, the whole point of modern package management systems like .deb and .rpm is to resolve dependencies with minimal or no user input. The usual solution in other formats is to specify a particular release or later, although that might not work in ever circumstances.
4. Snaps allow the installation of different versions of the same package.
True, but this feature is a characteristic of containers, not snappy packages. Containers can be installed on any distribution, regardless of its package management system.
Moreover, snap packages currently require Ubuntu's patched version of AppArmor to use containers. At least for now, to have this benefit, a snap package must be built on Ubuntu to have this advantage.
5. Snaps mean greater security because each package is isolated.
True, but again, the reason is containers. The greater security could be had, although with greater effort, on any distribution. Desktop users might get similar security with firejail, which is simple and lightweight.
In addition, although defense-in-depth — that is, by multiple methods — is always sound security, modern packages are signed, assembled and maintained conscientiously.
Asserting otherwise has apparently angered maintainers who are proud of their work. For example, Ikey Doherty, who maintains the Solus distribution, has argued on Google+ that he has no need of snap packages because of Solus' high standards.
Similarly, Debian veteran Josh Triplett writes that the reason for the high reputation of Debian packages is due not to the format, but to the Debian Policy, which sets the rigorous standards for packages. "Debian without the .deb format would still be Debian," Triplett says. "Debian without Debian Policy would just be Sourceforge, or rpmfind [two well-known archives of Linux software]."