Linux Mint 20 disables deb2snap packages, and Snap's growing external adoption problem

A year later, in the Ubuntu 20.04 package base, the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store.

Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store. You’ve as much empowerment with this as if you were using proprietary software, i.e. none. This is in effect similar to a commercial proprietary solution, but with two major differences: It runs as root, and it installs itself without asking you.

First, I’m happy to confirm that Linux Mint 20, like previous Mint releases will not ship with any snaps or snapd installed. Second, to address this situation we’ll do exactly what we said we would:

  • In 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 Linux Mint 20, APT will forbid snapd from getting installed.

I know that many of you who use Snap would probably find the above statements to have a significant bit of hyperbole, but I think that Snap developers really need to consider the amount of distributions bailing on Snap. We have Elementary OS, Linux Mint, Nitrux, Pop!_OS and others saying they will not officially support Snap. On Hacker News with the launch of Ubuntu 20.04, Snap received a lot of hate, with the most upvoted comments even being from Canonical employees.

I don’t want to bring up a dead horse, but I started a certain thread about External Repositories 3 years ago. I feared that Snap’s centralization, if left unaddressed, could harm Snap’s adoption. The developers said it wouldn’t be that big of a problem, and they’d cross that bridge when they came to it. That was 3 years ago, Snaps have no sign of decentralizing anytime soon, and major OSs are bailing.

If there’s anything we can gain from Linux Mint’s bailing out, I would hope that we would honestly consider the reasons why project leaders like Clement Lefebvre describe snap as being as good as a proprietary commercial solution, and actually address those claims instead of kicking it further down the road.

For a last indication of the times, take a look at Snap’s Wikipedia page. The criticism is almost half the article.


Whilst I think this is a perceived problem rather than a genuine one (the combined forces of the mentioned distros have voices out of proportion to the size of their userbase) it is hard to get away from the fact that perception influences morale, motivation and direction. We know that about two thirds of Ubuntu users are happy or neutral with snaps, and we know that snaps are a superior technological solution than the alternatives in several situations. Is the mistrust due to the closed source, centralised infrastructure or is it simply due to being associated with Canonical? If it’s the latter, I can’t see how that can ever be overturned. Do we beat on, boats against the current?

Can you please fix the topic to be less clickbait and sensationalist ? in your quoting you omitted the important part:

You’ll still be able to install it yourself and we’ll document this
in the release notes, but by default APT won’t allow repository
packages from doing this on your behalf.

so pretty please less drama, mint will disable the deb2snap transitional packages, thats all (and seriously, they have all the right to do this, diversity is the reason something like mint exists at all, nobody forces anyone to follow our path and this is a great example that you don’t have to)


In my experience, it typically appears that the proprietary closed source infrastructure is concern #1, and that this will result in Snap not getting adopted causing it to join the Canonical graveyard, which is concern #2.Concern #2 appears to directly result from Concern #1.

@ogra My bad. I didn’t realize this was deb2snap (where was my brain) and thought it was a custom implementation of a block.

That’s what is interesting. 66% is actually pretty bad if real. Yes, there is a majority, but it means there is a 33% dislike needing to be addressed. If you read Hacker News or the Ubuntu subreddit or Phoenix, the hate feels like 90%. Vocal minority? Perhaps, but Canonical hasn’t really done much to dissuade their specific concerns about the proprietary store, and people on HN are livid about the forced autoupdating. Canonical is taking a “my way or the highway” approach, and it appears the majority of distributions are choosing the highway (Flatpak).

Whatever you think about perception, perception is Snap’s biggest problem right now. It is seen as a Ubuntu-centric system, and we have several major developers outside Ubuntu like Clem oppose it. I guess I’m just asking Snap developers to actually start addressing concerns over things like the proprietary store instead of doubling down or thinking other things are more important than fixing perceptions.

Maybe things will go better for Snap, but it appears that at this rate, Ubuntu will be the only major distro with built in Snap support if this is not addressed. If that ends up being the case, Snap will die an early death, at least on the desktop.

I don’t know about that. I’ve seen @popey and colleagues patiently and thoroughly explain the model in numerous channels. I haven’t seen any convincing evidence that anyone would be motivated to build or maintain an alternative store (beyond trivial projects) and all the associated infrastructure. Why waste limited resources to appease a minority, when that minority are unlikely to embrace the product under any circumstances?


Elementary OS is a minority, but they sat on the Snap Technical Oversight Board and worked with Canoncial since 2016, and still rejected snap over this and other issues. They were arguably more invested than any other outside distribution. They wanted their own curated repo, but couldn’t. They also rejected the notion of sending any user data to a third party.

Fedora operates their own Flatpak store besides Flathub because they only ship FOSS stuff and Flathub had proprietary software in the repos. This wasn’t a problem for fedora and other FOSS-requiring distos: just make a new store. Shipping Snap for this very reason is a total nonstarter, as you can’t opt out of the non-FOSS packages.

I can go on.


With all due respect to Elementary, they’re not a big enough operation to maintain the infrastructure needed for a snap store. They’re still heavily reliant on Canonical as an upstream.

Fedora will pursue their own path, as they have done throughout their history. They are invested in flatpak to a similar degree that Canonical are invested in snap. It doesn’t make one approach more viable than the other.


I think both formats have potential, and find advantages in both. I just get upset when Ubuntu looks as if they are shooting themselves in the foot again… I want Ubuntu to succeed. I downloaded my first copy when I was 10 and it was 11.04. Passionate critic? I probably am, but I’ll still keep asking questions.


Saying that infrastructure like snaps are only useful for proprietary software ignores the difficulties traditional methods of software distribution on Linux systems causes for some open source projects.

Take Firefox as an example. As a web browser it represents a large Internet facing attack surface, which means it is important to keep it up to date. As Firefox is always evolving to improve web standard support, it isn’t always easy or desirable to try and backport security fixes to old releases, so there is also an incentive to run new versions on old distribution releases. This causes a problem when new Firefox releases rely on a newer tool chain (i.e. the C/C++ compiler, and now Rust too) than is available in those old distro releases.

With snaps, they can build the application against a more recent tool chain and have it run on the old distro. Further more, they can create one build that will run on all distro releases rather than repeating it for each.


My personal opinion on this topic.

Spending several years worth of engineering time to design and implement federation so that someone can run their own store with one package is not a good idea. The store is a non-trivial machinery and requires serious infrastructure to host and engineers to operate.

In the world at large, operating your own download stack is a liability more than a convenience. I realize FOSS has different priorities sometimes but I don’t think that making the store open would improve anything.

As for Mint, they can forge their own path. Let’s see the reaction before we jump at conclusions.

1 Like

There might be a PR gain in releasing the code in a “throwing it over the wall” approach (like Android). If anyone was motivated to run with it, there might be reason and motivation to support an open source infrastructure. I’m guessing it wouldn’t be easy to unpick the calls to the launchpad build service, web servers, single sign on infrastructure and social media portals, though, so (as an external observer who is only making wild guesses) I don’t think this will happen any time soon.

1 Like

@jamesh If you read what Clement said and what I said, you made a straw-man argument. We weren’t worried about Snap being only useful for Proprietary software. Our concern is the proprietary infrastructure necessary to run the Snap Store and the inability for anyone else to get that infrastructure. Everything you just said for open source projects can be done on Flatpak too and is not specific to Snap.

Yes, but it didn’t necessarily need to be that way. Flathub is open source and working just fine with other open source projects like Buildbot, even though Flathub was really Alex’s spare-time project. Even if you don’t think it will make a difference, there’s something reassuring about knowing you won’t be locked into the Ubuntu Snap ecosystem. Even if it doesn’t improve anything (which I strongly disagree with), it certainly wouldn’t hurt.

We shall see. However, this should be a warning for you and other developers. On the announcement page, it is literally almost universal applause for this decision. Just CTRL+F for Snap. There’s a lot of dislike in that crowd, and that should give us pause as to how that dislike got there.

It would be messy, but it would be a start. Just the headline that Snap server is now open-source would be a much-needed PR boost.

1 Like

Citation required. Large websites are complex and do things required to operate at scale.

Hosting a repository in a certain competitor to Snap is quite easy: The IDE supports it, and it’s almost as easy as just setting up a folder structure on a server. If you want something fancier, there’s If you want a GUI frontend website and not just a backend, there’s

And your Firefox analogy: . You can download the installation file, and you’ll see:

[Flatpak Ref]
Title=org.mozilla.firefox from flathub

It’s almost as easy as a file server. And yes, there will be a need to scale up, but I think most distributions can find someone knowledgeable enough to figure that out. After all, somebody has to handle the scale to download the distro in the first place.

1 Like

@zyga-snapd @jamesh My main worry with snap, especially if you read the many articles and videos about it above, is that the perceptions regarding snap are very poor at the moment in the broader community, and even though Snap could be viable on just Ubuntu, it would be a real shame to be so isolated to one distribution. This isn’t because I don’t like Flatpak. Ignore Flatpak, these users are openly opposed to the use of Snap at all. Solus is the only Linux distribution outside of Ubuntu to support Snap officially, and that’s because they support Snap and Flatpak together. 3 years down the road…

Bad news sells. Youtube folks happily talk about anything that’s click-baity. Ask app developers how they feel.


I care a lot about the user experience on Ubuntu, and the publisher experience for Ubuntu, and we should jump to address issues there.

For users, I think the primary issues have been themes and performance.

My understanding is that GTK3 themes are easier to address securely than GTK2 or other theme systems, because they are purely declarative CSS and not code injection mechanisms. My understanding is that we either have, or will soon have, good GTK3 theme support for desktop snaps.

On performance, my understanding is we now offer a different compression option for publishers which will offer a different tradeoff of size and compute speed. I say compute speed because ultimate performance is a combination of compression (how much you have to read from slow disks) and compute (how complex the decompress is). There are newer algorithms but they are not supported on a lot of distros, so publishers would be limiting their reach if we enable those at this stage.


We did that experiment with Launchpad; the people who said they wouldn’t use it because it wasn’t open source were the same people promoting a closed source alternative. When we open sourced Launchpad, they said that they wouldn’t use it anyway because Canonical was the primary contributor.

If you enjoy Catch-22 and Kafka’s dark comedy, the twisty arguments smart people use to justify not wanting to use a competitor’s stuff are hilarious.

Let’s just focus on making it absolutely amazing for anybody wanting to publish their app to Ubuntu users to do so, securely. And let’s make it amazing for Ubuntu users who want to try apps from publishers they have never met in person, to try apps, also securely. So far, that’s gotten thousands of publishers apps installed on millions of devices. And let’s be generous and say that any distro can take advantage of those apps, which helps them and helps the publishers. I feel good that we are doing that.


Fell or feel? (edit: haha, @zyga-snapd fixed it, feel it is)

If feel, I guess I fall into the category of an app developer as I have one out there.

I also feel I wouldn’t have developed and released it if snaps and the central snap store weren’t available.

As a long time Linux user, on and off with desktop use for 20+ years, but consistently for server use, in the last few years I returned to using desktop Linux far more consistently. Not being able to find a good text expander app, I scratched my itch and built Snippet Pixie.

A very big reason for taking the time and huge effort involved building Snippet Pixie was that I saw a path to being able to release it in a way that I could share it with other people needing such an app, but which would not involve me maintaining a package on many distro repositories, or users not being able to easily discover and install it.

That’s what the central Elementary AppCenter (hang in there, I’ll get to snaps in a sec) gave me as my first avenue of release, with great guides and community to help with the process of developing and releasing the app.

The Elementary AppCenter is a safe place for a developer to release an app, there are checks and quality controls in place that ensure your app meets a standard that helps prevent many potential problems for the end user. For me, this is a big deal, especially with an app like Snippet Pixie that’s already got many hurdles to jump just to do its job.

For all the love I have for the AppCenter, its a small audience in the grand scheme of things. And so, while I originally ended up building Snippet Pixie for the AppCenter, before I did so you bet I had spent a lot of time checking out all the ways I could release the app to a wider audience of people that need such an app.

As mentioned above, building for and maintaining across multiple distro package repositories, even if you just stick to the big ones that form the base of so many others, is just not feasible for a single developer with very little spare time. And while other people could package the app for those various distros, I felt like I’d have to put the app out somewhere first so that people start to use it, and hopefully give me feedback so I could improve it. From what I can tell, it’s not that easy to get into most repositories anyway, each distro has its own machinery to learn. And frankly, if Snippet Pixie does ever start to get any significant use and people start packaging it for their favourite distro, I’m scared to death of the potential explosion of issues that’ll be submitted.

So I always considered the “universal” package formats as being the only manageable method of release, that being AppImage, Flatpack and Snap.

At the time (a couple of years or so ago now), AppImage was very much a “release it on your own site” type of affair, no central discovery and install mechanism. And while that kind of control is attractive, and I’ve released software that way before, the lack of built in updates by default for AppImages is a no go for me. If there’s no built in update mechanism, whether silent or “hey, there’s a new version”, then as an app developer I’m not touching it. Previous software I’ve released has used the typical check for an update once a day mechanism, worked very well, users love just clicking a button to get an updated version, and I’m happy because the user-base keeps their versions up to date. Even so, I did try a few experiments with building a simple AppImage, and failed miserably. Getting the tools to just work, and even then get the very simple “hello world in a window” app to work was a terrible experience. I believe things have improved a lot since I tried to build an AppImage, and maybe it was just my own failings to pick up a new dev env, but at the time, nope, don’t need the pain.

Flatpacks also suffered from a lack of discoverability, Flathub was a thing, but wasn’t integrated into many distros, and not in any that I used at the time anyway. Being able to use Flathub to distribute updates was attractive though, so might have been worth the effort of detailing how to install flatpack support, but again, I seriously struggled to get a super simple flatpack to work.

Snaps on the other hand were a clear winner. There was a nicely designed central store that gave users confidence, app updates just worked, and there’s a clear beta/rc/stable mechanism front and center. At the time snap apps were probably only available in as many graphical installers as flatpack, but installing snapd and installing snaps was a breeze compared to flatpacks. So far easier to detail for end users. And crucially, building a snap with the excellent tools was also a breeze, it just worked. Sure, by “just worked” I mean after reading the nice developer docs and making sure I put things in the right place. But compared to the others where no matter how much I read it didn’t help, yup, it just worked.

Seeing how well snaps worked for me as a both a user and developer gave me the confidence to plow on and build Snippet Pixie. So even though I initially built the app for the AppCenter, I always knew that if it seemed to be a goer and worked as an app, then I’d build and release a snap for wider use too.

Having a snap store backed by a trusted company like Canonical, which includes many individuals that are active in the wider Linux community, and forums like this where I could see frank discussions and plenty questions and answers on technical or otherwise subjects related to snaps, just gave me confidence to have a go. I’m really not sure how spending the time and money to try and refactor the software stack for what must be a pretty darn complex store so that it can be easily open sourced is a good idea. As an app developer I want a platform that enables easy discovery and distribution of my open source apps in an open source package format. The important part to me is that the package format can be audited as that’s what’s running on user’s machines. A large app store like the snap store will have many moving parts, and I very much doubt many other parties are going to be in the position of being able to customize and run such a beast. Having an open source store would be nice, but given that as an app developer I’d prefer to deal with as few channels of distribution as possible, I personally don’t see any need for that kind of mammoth effort by Canonical, unless they truly see a benefit to letting people audit their software stack.