Linux Mint drops Ubuntu Snap packages

By John Coggeshall

July 8, 2020

The Linux Mint project has made good on previous threats to actively prevent Ubuntu Snap packages from being installed through the APT package-management system without the user's consent. This move is the result of " major worries " from Linux Mint on Snap's impact with regard to user choice and software freedom. Ubuntu's parent company, Canonical, seems open to finding a solution to satisfy the popular distribution's concerns — but it too has interests to consider.

Backstory

The Linux Mint distribution is based on Debian and Ubuntu, providing over 30,000 packages from these projects. These packages are provided using the well-known APT packaging system used by both upstream distributions. Ubuntu, however, in 2014 started distributing software in parallel to APT using a technology called Snap .

Snap is a self-contained package-deployment system designed to make it easier to manage dependencies of an application in a Linux environment. Developed by Canonical, Snap is designed so that its packages contain all of the specific dependencies a software package needs to run, bundled into a single filesystem image. This allows a software package to run on a system that has otherwise incompatible versions of needed libraries, or even to have two different versions of a single software package with different dependencies easily coexist on a single machine. Essentially, it allows one package to be created per architecture that can run on any common Linux distribution.

The technology solves important package-management problems for Canonical and Ubuntu. It also has a strategic business value, as it allows Canonical-managed software to be installed on a competing distribution. The technology problem Canonical wants to solve is to simplify support for software packages, such as Chromium , across the multiple versions of Ubuntu. Relying strictly on APT requires independent packages to be maintained for each Ubuntu version, since various Ubuntu releases ship with different and potentially incompatible libraries. This represents a large workload that Canonical would rather not deal with, and to which Snap provides an elegant technical solution.

From a business perspective, widespread adoption of Snap as a universal package-distribution technology would put Canonical in a strong position to control Linux software distribution. This fact is not lost by Canonical's competition — Red Hat supports a similar Flatpak technology. Unlike Snap, however, the Flatpak project aims to be an independent community and a " true upstream open source project, dedicated to providing technology and services that can be used by all, with no vendor lock-in. "

The problems with Linux Mint came to a head when Ubuntu moved Chromium to Snap distribution in Ubuntu 19.10. On the surface, that isn't a problem in and of itself — the Linux Mint project can always start providing its own Chromium APT packages. The problem was the decision to change the Ubuntu chromium-browser APT package itself upstream in Ubuntu. Previously, that package would simply install Chromium directly. With the change, it would instead install the Snap package-management tools first and then install the Snap equivalent of the Chromium package — without making it clear to the user what was happening.

This behavior isn't limited to Chromium either, Canonical is using this approach on other packages as well , such as gnome-software . This decision to use APT to install a secondary, commercially-controlled package-management system, which then installs the software the user wanted, is the center of the controversy with Linux Mint. As was reported on the Linux Mint blog when the Chromium change was made:

A self-installing Snap Store which overwrites part of our APT package base is a complete NO NO. It's something we have to stop and it could mean the end of Chromium updates and access to the snap store in Linux Mint.

What's at stake and recent events

The recent decision by the Linux Mint project isn't about Chromium or any single package, but rather about the entire approach Canonical is taking to Snap and APT. Snap packages are effectively black-boxes; they cannot be reproduced independently as the packaging data is controlled by the package maker alone. Further, the Snap package manager is locked into Canonical's library (called the Snap Store) so independent third-party Snap repositories aren't currently an option, either. While Snap packages can be downloaded and installed from other sources manually, doing so requires passing along a rather ominous --dangerous flag.

According to Canonical Engineering Manager Ken VanDine , the decision to replace APT packages with Snap is driven by efficiency, and to apply pressure in ways beneficial to Canonical. Regarding moving the gnome-software APT package to Snap, VanDine said:

By shipping such a key application as a snap it will continue to keep pressure on to ensure we keep improving the experience while also reducing our maintenance burden for the LTS and future releases of Ubuntu.

So while the Linux Mint project took action specifically when Ubuntu's decision impacted the popular chromium-browser package, it seems this was more of the tipping point for the project than an isolated concern. According to the project, these moves from Canonical " could reduce access to free (as in beer) software and free (as in freedom) software. " It wasn't a sudden decision either — a year ago the Linux Mint project wanted to find a reasonable solution to the problem by working with Canonical, however nothing seems to have come of those conversations. In fact, it is unclear if any conversations happened at all.

What is known is that, when Ubuntu 20.04 was released a year later, the APT package that installed Chromium still installed the Snap version without the consent (or necessarily even knowledge) of the user. In response, the Linux Mint project made good on its previous threat; starting with Linux Mint 20 " Chromium won't be an empty package which installs snapd behind your back. It will be an empty package which tells you why it's empty and tells you where to look to get Chromium yourself. " In addition, Linux Mint 20's APT package manager " will forbid snapd from getting installed. " The project doesn't appear to be outright forbidding users from using Snap if they want to, but doing so would require explicit action from the user as " by default APT won't allow repository packages [to install Snap] on your behalf. " Presumably this applies to any package that Ubuntu has migrated to Snap upstream — including both chromium-browser and gnome-software .

It appears the decision had an effect, and prompted Canonical to at least discuss a change in course according to recent reporting by ZDNet . A representative from Canonical, quoted by ZDNet, said:

We would welcome Linux Mint to engage with us and our community to discuss such topics, as we do with other distributions, and work together going forward.

Canonical's community manager for Ubuntu engineering services, Alan Pope, provided a justification specifically for the migration of Chromium to Snap. The justification, however, didn't cite the idea of keeping " pressure " expressed by VanDine regarding other packages like gnome-software :

Maintaining a single release of Chromium is a significant time investment for the Ubuntu Desktop Team working with the Ubuntu Security team to deliver updates to each stable release. As the teams support numerous stable releases of Ubuntu, the amount of work is compounded. Comparing this workload to other Linux distributions which have a single supported rolling release misses the nuance of supporting multiple Long Term Support (LTS) and non-LTS releases. [...]

A Snap needs to be built only once per architecture, and will run on all systems that support Snapd. This covers all supported Ubuntu releases including 14.04 with Extended Security Maintenance (ESM), as well as other distributions like Debian, Fedora, Mint, and Manjaro.

It will be interesting to see what if anything comes out of this to facilitate a resolution between the parties. In its blog posts , Linux Mint has mentioned various changes to Snap, such as allowing third-parties to run independent Snap package servers, that might help get to a solution. As the project wrote, " snap could work both as a client and a file format, if it didn't lock us into a single store. " Doing so, however, would likely run contrary to Canonical's strategic goals.

What's next

It's important to realize that, fundamentally, a technology like Snap would be useful for those who create packages, including proprietary software vendors. The problem in this case doesn't seem to be the technology, but Canonical's sole control over it — and the way it's being introduced through APT. As the Linux Mint project stated in its 2019 post:

[Snap] was supposed to make it possible to run newer apps on top of older libraries and to let 3rd party editors publish their software easily toward multiple distributions [...] What we didn't want it to be was for Canonical to control the distribution of software between distributions and 3rd party editors, to prevent direct distribution from editors, to make it so software worked better in Ubuntu than anywhere else and to make its store a requirement.

Ultimately there are multiple interests at play here leading to uncertainty on how things will work out. On one hand, you have companies like Canonical that see the strategic value of controlling the technology behind application distribution, and is using it to apply pressure where it wants to see change. On the other hand, you have distributions like Linux Mint that are prepared to actively block the technology while it is controlled by a single commercial interest. Hopefully this latest move by Linux Mint will prompt a change toward more openness, as a packaging system like Snap implemented in an open way would be a win for the entire Linux community.

to post comments)