Snapcraft Suitability

doc
1

:warning: This is a work-in-progress draft document intended to be edited by others. It came about after a conversation between some experienced snapcrafters. It may be helpful, or it may not. Please contribute.

The goal of this document is to provide an answer to the question, “Is this thing suited to being a snap?”. Enthusiastic contributors looking to snap things may want to reference this document.

It may contain opinions, but it would be better if it were objective facts. The document may change over time as the tools and platform evolve.

:warning: Note that some things may not make sense to package in isolation but may make sense when bundled in a snap with other things, either in a leaf “application” snap, or in a “content” snap.

Absolutely yes

These are classes of applications which snap is well suited for today. There’s a ton of prior art here.

  • Desktop applications - Built using GNOME, KDE, Electron
  • Command-line utilities - Shell scripts, Python programs, or tools written in Go or Rust
  • Games - Built using SDL, Unity, Defold
  • Servers - both single application/components, and multi-component bundles

Qualified yes

These are also possible, but may require some work beyond actually snapping the application, or need approval for publishing.

  • Backup utilities - will likely require classic confinement to work correctly
  • System components - will almost certainly require additional interface development

Qualified no

These might be possible, but will almost certainly require a conversation with the store review team or snapd development teams to get these over the line. Even then, the answer may well be “no”.

  • Application storefronts - as these may bypass store approval / vetting process
  • Orchestration tools - likely to require classic confinement and will almost certainly install additional software

Almost certainly not

Highly likely these things will just not work well when snapped in isolation, but might make sense as part of something else - such as in the case of libraries.

  • System libraries - will be inaccessible to most applications
    • Examples: zlib1g
  • Headers - they’ll likely be installed somewhere inaccessible by build tools
  • Shells
    • Examples: Bash, Zsh, fish
2 Likes
2

System Libraries as a content snap? Like ffmpeg, gnome libraries, and even zlib1g, if someone makes it?

3

@soumyaDghosh this is explicitly already called out.

4

Sorry, I was not able to understand it properly. May be we can mention the content snap word there?

1 Like
5

@popey Your forgot one under “Absolutely yes”: System components and server software

These are for example CUPS, ipp-usb, network-manager, MySQL, …

They allow:

  • Modular composing of a server based on Ubuntu Core, either by installing Snaps on a running Ubuntu Core, or by creating a model for building an Ubuntu Core image which comes right away with the desired server configuration
  • Modularizing the system components in Ubuntu Core Desktop, so that they get updated independently and therefore more frequently.
  • Quick and easy hardware enablement, by Snaps of Printer Applications, Scanner Applications, NVidia drivers, …
  • Independent of whether one uses a classically installed distro, Ubuntu Core (Desktop), NixOS, … having the latest and greatest versions from upstream, especially if upstream is actually the snapper.

Want to know how to snap system software? Go here.

1 Like
6

Thanks @till.kamppeter !

I went with “Qualified yes” for system components, because while they absolutely can be done, for any new component, there’s almost certainly going to be some interface development required. I’ll add some qualifiers under the headings so it makes things clear.

1 Like
7

And do not forget about all these special Snap types for Ubuntu Core (Desktop): Gadget, kernel, core, desktop session … Especially with the desktop session Snaps we can easily get all the flavors as Core Desktop … @popey, a lot to show on your Steam Deck on the next Summit …

3 Likes