Distribution support status

snapd
1

Latest release: 2.65,1 github releases. See snapd roadmap for details.

Repology overview

Packaging status

We use a third-party tool called Repology to track snapd version numbers across various Linux distributions.

On some distributions, a non-snap package will install the snapd snap which will subsequently update itself. This process is called re-execution. On such systems, Repology can only detect the version number of the native non-snap package and not the updated snapd from the snap.

Distributions that have reached their end-of-life are excluded from the list.

Ubuntu

Ubuntu 14.04 package Ubuntu 16.04 package Ubuntu 18.04 package Ubuntu 20.04 package Ubuntu 22.04 package Ubuntu 23.04 package Ubuntu 23.10 package Ubuntu 24.04 package Ubuntu 24.10 package

Due to distribution policy snapd is not regularly updated to the latest available version. Snapd re-execution is supported on Ubuntu. The versions listed above are usually only relevant before the installation of the first snap. Outside of unusual circumstances, the Ubuntu package is synchronized from Debian. This process stops once an upcoming Ubuntu release is entering feature freeze.

Debian

Debian 11 package Debian 12 package Debian 13 package Debian Unstable package

Due to distribution policy snapd is not regularly updated to the latest available version. Snapd re-execution is supported on Debian. The versions listed above are usually only relevant before the installation of the first snap.

Resources for developers:

Fedora

Fedora 39 package Fedora 40 package

Fedora Rawhide package

Fedora allows updating packages in stable distributions. You can expect all snapd releases to be updated within a week or two of the upstream release, following the usual testing and migration process. Due to ABI incompatibilities, differences in build configuration process and distribution policy snapd re-execution is not supported on Fedora.

Resources for developers:

EPEL (RHEL, CentOS, Alma Linux, Rocky Linux, etc)

EPEL 7 package EPEL 8 package EPEL 9 package

Snapd is not directly available in the Red Hat family of enterprise distributions. It is freely available and maintained in the commonly used EPEL (extra packages for enterprise linux) repository. You can expect all snapd releases to be updated within a week or two of the upstream release, following the usual testing and migration process. Due to ABI incompatibilities, differences in build configuration process and distribution policy snapd re-execution is not supported on any of those systems.

openSUSE, SUSE Enterprise Linux

Snapd is not directly available in the openSUSE or SUSE archive. Instead the package is maintained in the system:snappy project in Open Build Service (OBS), making it easily installable on the family of related SUSE distributions. You can expect all snapd releases to be updated within a week of the upstream release. Due to ABI incompatibilities, differences in build configuration process and distribution policy snapd re-execution is not supported.

Distro Version Reexec
SLE 15 2.52 n
Factory 2.65.1 n
Leap 15.5 2.65.1 n
Leap 15.6 2.65.1 n
Tumbleweed 2.65.1 n

Resources for developers:

Arch Linux

AUR package

Snapd is available in the Arch User Repository (AUR). You can expect all snapd releases to be updated within a week of the upstream release. Due to ABI incompatibilities, differences in build configuration process, snapd re-execution is not supported.

Resources for developers:

Manjaro

Manjaro Stable package Manjaro Testing package Manjaro Unstable package

Resources for developers:

Gentoo

Gentoo package

Resources for developers:

Solus

Solus package

Snapd is available in the distribution archive. You may have to run extra commands to enable the snapd.socket and the snapd.apparmor.service. See TBD - installation instructions missing.

Resources for developers:

Amazon Linux

Package repo: snapd-amazon-linux (unofficial)

Snapd upstream packaging: snapd upstream

Instructions Unofficial snapd repositories for Amazon Linux

Distro Version Reexec Notes
AL2 2.63 n unofficial
AL2023 2.63 n unofficial

Yocto layer

A Yocto meta-layer called meta-snapd exists, allowing the use of snapd and snaps on custom-build system images. Individual branches are named after Yocto release names.

Snapd Release Yocto Release Kernel Recipe Kernel Version Confinement
2.61.2 kirkstone linux-yocto 5.10 strict
2.61.2 kirkstone linux-yocto 5.15 strict
2.63 nanbield linux-yocto - partial
2.63 scarthgap linux-yocto - partial
2.63 master linux-yocto - partial

At present master branch does not build as meta-security is being updated to support changes happening in Poky.

7 Likes
2

Do we still have the yocto snapd ? if so, might be nice to list it here too …

3

Yes and both Maciej and me have been maintaining it in our previous job. I have a work-in-progress 2.61 branch that got stuck on updating the kernel patches. We will definitely bring Yocto into the fold of places we maintain snapd.

3 Likes
5

Good to see movement cross-distribution. This Distribution support status provides great information. Huge thanks to mborzecki1 for that. Info/status if full confinement is available would be also great. And zyga (and probably others) for shaping up snapd support on different distributions in the last few weeks.

6

We have a plan for a confinement dashboard that shows all interfaces and distributions and their status. This will take some time to assemble though. We need to have some automation, as it is not very feasible to do by hand.

1 Like
7

Why on earth is distrowatch dot com listed up there? It’s a news website, not a repo.

8

I was wondering about this myself and I suspect it could be some sort of meta-upstream tracker. For instance snapd version is listed on distrowatch: https://distrowatch.com/packages.php#snapd

I would be happy to remove it, perhaps there’s a way to not track it somehow using query parameters?

9

Yeah, I found that page too. I guess this is a question for repology. Very odd.

10

I’ve updated the part for Yocto, there will be more updates as we support additional releases.

1 Like
11

Hi there! Should the snap core be included on the table?

Thanks!

12

Why would that be relevant for the ability to install snaps on a system ?

Once you have a working snapd you can just snap install core, completely independent from whatever system your host runs. (And it should indeed also be pulled in when you install another snap using it as a base)

13

OK, I might be missing something then: my concern was that the core snap usually takes more time to be updated to the current version of snapd than, for example, the snapd one. For example, right now all channels, except for latest/edge, are on version 16-2.61.2 on the core snap.

But maybe I’m talking nonsense and that doesn’t belong here, sorry if that’s the case.

14

Ah, i see what you mean…

In ancient times (2016 :wink: ) snapd actually used to re-exec into the core snap in ubuntu to execute itself… but that changed with the creation of the snapd snap.

There might still be some 16.04 (and UbuntuCore 16) systems running it that way, but I doubt that’s actually a large margin …

Non ubuntu/debian does not re-exec at all though, these distros need their native snapd package which is what the table above tries to project…

1 Like
15

I have a server running Ubuntu 20.04 which still uses the core snap, instead of the snapd snap; I guess that’s because it was originally on 18.04 and I updated it in place.

And now that I’m thinking about it: is there any way to “upgrade” my system to use the snapd snap?

16

Just snap install snapd should be enough…

note that the core snap will still be used as execution environment for application snaps, it will still stay installed…

17

With regards to SUSE. Is this issue still a blocker? Will it get back on @zyga or @zyga-snapd radar? Inquiring minds would love to know.

https://github.com/snapcore/snapd/pull/6714

18

We’ve been drafting plans for the next six months and proposing snapd into factory is on the radar.