Why is Ubuntu moving to Snap packages?

Question

Why Ubuntu dumping .deb packages and moving to .snap packages?

At least for now they are keeping .deb package for normal distributions. .deb is already the most popular packaging format out there.

This gives an idea about what the Snap package format is. But what will happen to the existing deb packages? Is there any clear advantage on moving to Snap? Is it worth the pain?

Solution 1

Snap attempts to solve one of the fundamental problems with Linux as a desktop operating system: software availability and software distribution. Snap is not intended to completely replace debs, however. Snaps and Debs work alongside each other.

I am a Linux enthusiast and a project manager of a Linux application. While I love Linux systems as a whole, I can't stand the current state of package distribution. Universal App Formats like Snaps aim to solve this fundamental problem.

In Linux, packages are specifically built for a single version of a single distribution. With a lot of tweaking, it is possible to make one .deb package that runs on all Debian based systems, but this is complicated and limits developers. It's also not practical at times due to version locking of dependencies.

If I create a deb package for Ubuntu 20.04, it will only work on that version. I also have to make a different package for 16.04, 18.04, 20.10 and so on. I already have to make four packages just for Ubuntu. I also need to make one for every Debian version, every Fedora version and every openSUSE version. RPM is more flexible in this regard but the locked dependency issue still gets in the way.

This means if I want to release a new version of my application, I have to create over 20 packages to cover the majority of Linux distributions, and that still won't cover every distro. A second possibility is to wait for distribution maintainers to add your package to the distribution but this usually takes an absurd amount of time. Moreover, then the distribution maintainers decide which version their users get instead of the software developer.

With Snap, a single package runs on every version of every distribution that supports snap. See Installing snapd for a list of many distros that support it.

Additionally, with Snap, the developer publishes and maintains the package, instead of the distribution maintainer. So I as a developer can release new a version to all my users without having to wait on anyone else.

Essentially, everything I hate about Linux package distribution is solved by Snap. Though it's important to note that these core issues are also being solved by Flatpaks & to a degree by AppImages. The discussion for which format is better is highly debated and a much longer conversation than makes sense for this reply. For now, I will say that I am fine with running any of the universal formats since they all work differently and thus do not conflict with each other making it possible to run all 3 and traditional packages at the same time.

TL;DR

Linux package distribution is awful for both developers and users. Snaps, Flatpaks & AppImages are intended to solve this fundamental problem with Linux based systems.

---

This question is really about why the move but if anyone is interested in learning more about what Snaps are and how they work. I created this video to explain the structure in-depth.

Solution 2

It's just simple. Snappy package contains all the required files, where .deb packages have dependencies to other packages.

The negative side is that snappy is bigger because it contains all the files. But the big advantage is that you don't get in trouble with other packages and if you remove this package, no other package will be affected by missing dependencies.

Solution 3

Snappy Personal, their new approach to package management/updating that's designed to be faster, more reliable, transactional, and with stronger security.

Snappy for at least one of their desktop spins -- the plan is to switch Ubuntu's Desktop-Next spin from .deb over to Snappy Personal.

.deb will still there and a normal user can still use it regularly by the time converting the .deb to snappy.

Snappy will be used to unify the concept of package management among the ioT which is using snappy now as its core Os. moreover snappy provide a better way in updating and get rid of problem while update/upgrade since it use the concept of whole image which means the update will be just one piece and therefore no means of fail

Read those articles for more info:

http://www.webupd8.org/2015/04/ubuntu-desktop-to-eventually-switch-to.html

http://www.itworld.com/article/2914850/linux/is-ubuntu-moving-away-from-deb-packages-here-is-the-complete-story.html

There is also a QA video from ubuntu on air that answers a great many questions https://youtu.be/lHO8j8uo5Z4

Solution 4

Consider moving to snappy Ubuntu Core today if you are thinking of creating something for others to use, in other words, a product.

The software is delivered in snaps, which given its traits, we can have confidence that installation and upgrades will work on every system as the original creator intended. Other traits are security, such as isolated execution and clean interfaces to talk to the system and configure the installed snaps.

To achieve such a thing, snaps differ a lot from are much different than a debian package:

• snaps live in an isolated system determined location while debian packages can spread files all over the place.
• there are no maintainer scripts for snaps.

Going back to the original question of to use or not to use, if you plan to replace your desktop with Ubuntu Core I suggest you stick with regular Ubuntu desktop. Ubuntu Core, I personally like to call, the nothing distro, because alone it is nothing, but provides a very good building block to offer something and this is why it is popular in IoT these days.

View more solutions

Comments

[Admin]

The link is borken

[Vishnudev K]

why can't they make a .deb version 2 package with backward compatibility? Why making a split in linux community?.For now the plan is to slowly migrate to Snappy unless it is utter flop.

[Maythux]

they want to unify the concept of package management among the ioT which is using snappy now as its core Os. moreover snappy provide a better way in updating and get rid of problem while update/upgrade since it use the concept of whole image which means the update will be just one piece and therefore no means of fail

[Wilf]

Its bad enough with the large variety of methods for packaging in Linux (which already causes issue with third party programs), another one will just make a bigger mess :-/

[sergiusens]

That is a broad question. What does Windows do in particular?

[Vishnudev K]

I am installing VLC in windows, it install all the packages needed to hog the space. where as in linux we get only the packages we dont have. Its pretty convenient in terms of updates and hdd usage.

[sergiusens]

Similar, yes. It is no different to installing an apk on your phone. Applications can evolve with their dependencies as they see fit. There are ways to split this up though, like by using framework snaps, this requires tight security review though. The difference with Windows is that there are not installers here potentially being able to land wherever they want.

[TRiG]

@Maythux. What is an ioT?

[John Franklin]

Gosh, you make it sound so hard, except nobody ever supports that many versions of Fedora, Debian, or Ubuntu. By the time 16.04 is out, 15.04 is EOL. By the time Fedora 23 is out, F21 has less than a month of life left, just long enough for people to skip a release. Not that it would matter. Once you've got the base RPM spec file or the base Debian package written, the other distros are tweaked versions, and then it's just a Jenkins job to build them for every new release.

[Tiit Papp]

Ubuntu packages are made for that many versions: 14.04, 15.10, 16.04 and some continue supporting old LTS like 12.04 which is still supported. || Fedora has no LTS so yea less versions to support but still at least 2 versions with possible 3 versions to support. || What sounds better to you? A. make multiple packages of each version of the same application for one distro and do that for multiple distros. OR B. make one snap for each version of your app and that works on whatever distro and whatever version of said distro. Yea, I vote for snaps in that scenarios.

[John Franklin]

A. Multiple packages, because with option B I'm now responsible for tracking security updates for all components in the snap and updating the snap every time a security update comes out for any of them. Let the distro worry about that. || When a new version of a distro is released, there is no obligation to update previous versions. Let's say Fedora 23 has version 1.0 of my package, and Fedora 24 1.1. Fedora 23 may never see an update to 1.0 unless I'm backporting a critical bug fix to make 1.0.1, in which case I still have the original spec file on the 1.0 branch in git.

[Tiit Papp]

Well most people disagree with you and I can tell you for a fact that many companies choose to ignore Linux due to Option A. || Keeping track of security of your app is too hard? Developers should be doing that regardless of snaps or not. || There is no obligation to update previous versions . . . true just as there is no obligation to release software but arbitrarily having different versions of software depending on distro and distro version installed is silly. We disagree on this fundamentally it seems but I guess we can leave it at that since neither are likely to change our minds.

[user]

@Maythux xkcd.com/927

[user447607]

IMHO, more redundancy and consequently less performance is not an answer. Anyway if we wanted to do redundancy, we wouldn't need a new package management system. Agree w Wilf that it will just be a bigger mess.

[user447607]

IMHO, more redundancy and consequently less performance is not an answer. Anyway if we wanted to do redundancy, we wouldn't need a new package management system. Agree w Wilf that it will just be a bigger mess.

[Tiit Papp]

@user447607 You are misunderstanding what Snaps and Snappy is. There isn't going to be a bunch of redundancy, there will be runtimes and there will be options to have snaps depend on other snaps to save space. This is already possible, in fact. Snappy is a different package management system that handles snaps and apt is still involved with DEBs. Snaps do not replace DEBs, instead they augment DEBs so you get a hybrid approach that covers both methods. In fact, Snaps can be automatically generated via existing DEBs.

[Jürgen A. Erhard]

It also means security nightmare. Oh, please prove me wrong... because being right would be so horrible.

[Pithikos]

So essentially they are taking the Windows path - which ironically was mocked by Linux-ers in the past.

[konung]

@MichaelTunnell How are snaps different / the same as docker containers? It's seems to me they provide similar functionality? No? P.S.: Just discovered SNAP to my amusement.

[Tiit Papp]

@konung Docker is purely containerization where as Snaps have that as well as integration with system core components. For example, Docker requires everything to be included in the container to use it. However, Snaps only require the necessities to be included and then it could look outside of the snap to utilizes other things. Snaps also have a MUCH better infrastructure because Docker has no real update mechanism but Snaps utilize a similar package management system to APT for Debian. I suggest checking out the video I linked in the original post. I plan to make an updated version soon.

[konung]

@MichaelTunnell Thank you. I will watch it over the weekend!

[konung]

@MichaelTunnell How is data from the snap persisted from version to version? Let's say MySQL snap - where is DB data stored/saved? And how is it affected by the updates? ( Doesn't have to be MySQL - any other snap that you might be more familiar with would work as an example)

[Tiit Papp]

@konung Snaps are not containers. A lot of people compare them to Docker for example but Docker is true containers where as Snaps are not. Snaps are container-like but they are not full containers because they allow for exceptions outside of the confinement. For example, the settings/configs/data stuff is stored outside of the Snap inside of the /home folder. This way you can have as many versions of a snap as you want all sharing the same data/configs.

[Tiit Papp]

You're welcome. Glad I could help. :)

[Qian Chen]

I switched from Ubuntu to Arch. Life couldn't be easier. All packages are up to date, which apt-get just failed.

[Tiit Papp]

@Elgs Qian Chen until you run into dependency issues with some apps updating and others not doing so . . . Also with the AUR having to rebuild every application you use and even slightly out of date dependencies will break the pkgbuild . . . and so on. All Operating Systems have issues, you just have to find what issues you are willing to deal with.

[Qian Chen]

@MichaelTunnell I have been using it for 6 month and I haven't had a single issue. I had enough with Ubuntu that the package manager just doesn't do the work as I expected. Maybe I am particularly obsessive about latest version. Also in Arch community, if something is broken, it's usually fixed in hours. To be fair, Ubuntu is still the most usable (I mean desktop) Linux if I didn't know Arch Linux.

[Tiit Papp]

@Elgs Qian Chen I don't mean it as a suggestion that you shouldn't use it. I think you should use whatever you want. I just prefer to clarify statements regarding Arch so people don't randomly find threads saying how great it is without mentioning the caveats. It has a lot of upsides but also downsides as well. I'm actually a contributor to an Arch derivative so I've seen a ton of ups and downs over the years. :)

[Ilya]

Hey @JürgenA.Erhard, as I understand, each package will have it's own libs, for example cryptography, so instead of verifying one (i.e. self-compiling), you have to basically deal with every package individually, is that what you meant by "security nightmare"?

[Tiit Papp]

Correction: "contains all the required files" is not accurate as there are core snaps that act as runtimes. However, this was added after the original answer so it was correct at the time but a lot has changed since then.

[Fran Marzoa]

"Though it's important to note that these issues would also be solved by Flatpaks." So if we end up having a myriad of Snap-like systems with each distribution using its own one, wouldn't we be where we started?

[Tiit Papp]

@Fran Marzoa, Snaps, Flatpaks, and AppImages all work independently from the distro itself so they can be ran on any distro. This means it doesnt matter what distro someone is using as everything would be available to the user.

[Fran Marzoa]

@MichaelTunnell I understand, but won't that produce conflicts if you have the same package in different systems?

[Tiit Papp]

@Fran Marzoa actually no, you can install Snaps, AppImages, Flatpaks, and DEBs/RPMs at the same time if you'd like to. There could be issues of running some combinations at the same time but installing them is fine. For example, I have Firefox DEB and Snap installed right now. I can only run either the DEB or the Snap at a time but I can close one and open the other with no issue at all.

[Marinos An]

I never use sudo to install 3rd party software. I was glad to find out that I could install vscode using flatpak without prefixing with sudo.

[jchook]

In my experience, the "snap" version of some packages (e.g. Skype) opens very slowly compared to the same software installed with apt-get.

[Tiit Papp]

@jchook This is true in some cases because it will need to load more stuff the first time but after the initial loading process it should be fine with repeated opens. However, Skype is deprecated in apt so the Snap is VERY different and a lot heavier now so that isn't a good example.

[Tiit Papp]

@MarinosAn you also dont need sudo for using AppImages but Snaps work differently as they dont have access to alter every system file like debs can do. Flatpaks have other issues, like not being able to automatically be updated.

[admirabilis]

@MichaelTunnell Snaps can be automatically generated via existing DEBs - there is no indication of that anywhere in the documentation. In fact, building Snaps is always incredibly more difficult than building DEBs, and the documentation is very lacking.

[Tiit Papp]

its not going to be a bigger mess . . . what we already had was a giant mess that made companies ignore Linux. Even with 3 competing formats like Snap, Flatpaks and AppImages we are making it simpler by dropping 30-40 packages down to 3. This is certainly an improvement.

[Jason Kleban]

And are they worth 10.5s of my 26s boot time for snapd.service & snap.lxd.activate.service??

[Tiit Papp]

@JasonKleban in my opinion, absolutely! Taking slightly longer to boot vs taking months and months to get updates . . . yea I'll choose waiting a few seconds for booting any day.

[firstpostcommenter]

So snaps are like .pkg of MAC which are mostly self contained with all required things?

[Gabriel Staples]

@AlexWLBI, Citing some references here for this answer would be really useful so we can see where you're getting this information.

[stephanmg]

So the biggest advantage is that there are more releases/updateso of the package?

[Long]

talking about security, I read this from r/kyrofa "Debs are typically frozen when an Ubuntu release is cut, and that deb typically won't see an update over the course of the Ubuntu release. Depending on the repo it might see security updates and maybe bugfixes, but that's the exception. However, snaps are outside of the distribution, and can be updated at any time, which means the snap could very well be much newer than the deb. .. PPAs allows debs to be updated outside of the distribution but these require putting your trust in a particular person rather than the maintainers of Ubuntu. "

[Tiit Papp]

@stephanmg the biggest advantage is that version locking wont happen. The biggest issue with DEB/RPM style is that if an app needs a new version of a library and that library is locked then that app can never be upgraded until the whole system is upgraded. Snaps allow the app to bypass that lock meaning each app can be updated whenever available. The security confinement is a nice bonus too. :D

[stephanmg]

@MichaelTunnell thanks! This makes a lot of sense now.

[Tiit Papp]

@stephanmg you're welcome :D