• Type:

CH Linux Mint drops Ubuntu Snap packages

Welcome to LWN.net

The following subscription-only content has been made available to you
by an LWN subscriber. Thousands of subscribers depend on LWN for the
best news from the Linux and free software communities. If you enjoy this
article, please consider accepting the trial offer on the right. Thank you
for visiting LWN.net!

Free trial subscription

Try LWN for free for 1 month: no payment
or credit card required. Activate
your trial subscription now
and see why thousands of
readers subscribe to LWN.net.

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.






Did you like this article? Please accept our
trial subscription offer to be
able to see more content like it and to participate in the discussion.


(Log in to post comments)

Read More

Previous Post

CH Show HN: Runnaroo – A new search engine

Next Post

Building Cloudflare TV from Scratch

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top