Difference between revisions of "Guidelines and HOWTOs/Snap"

Line 440: Line 440:
And lastly we can drop our summary and description fields in favor of adopting the information from the parsed appstream data of our kmplot part:
And lastly we can drop our summary and description fields in favor of adopting the information from the parsed appstream data of our kmplot part. The entire refined snapcraft.yaml should now look something like this:
{{Input|<syntaxhighlight lang="yaml" line>
{{Input|<syntaxhighlight lang="yaml" line>
Line 450: Line 450:
base: core18
base: core18
adopt-info: kmplot # part to adopt from (first in parse list)
adopt-info: kmplot # part to adopt from (first in parse list)
        command: kf5-launch kmplot
        plugs: [x11, opengl, desktop, desktop-legacy]
        common-id: org.kde.kmplot.desktop
    session-dbus-interface: # semi-arbitrary name
        interface: dbus # type of the interface; this allows snapd to restrict/allow what is necessary
        name: org.kde.kmplot
        bus: session
        plugin: cmake
        source: https://anongit.kde.org/kmplot.git
        source-branch: Applications/19.04 # not needed for master
        configflags: ['-DCMAKE_INSTALL_PREFIX=/usr']
        build-packages: [build-essential, extra-cmake-modules, libkf5widgetsaddons-dev, libqt5svg5-dev, libkf5parts-dev, libkf5doctools-dev, libkf5crash-dev, gettext]
        stage-packages: [libkf5widgetsaddons5, libqt5svg5, libkf5parts5, libkf5crash5]
        parse-info: [usr/share/metainfo/org.kde.kmplot.appdata.xml]
        plugin: dump
        source: https://github.com/apachelogger/kf5-snap-env.git
        source-branch: standalone
        stage: ['-kf5/']
        plugin: nil
        stage-packages: [plasma-integration] # this also pulls in all of breeze
Line 455: Line 485:
This snap is now in a very good shape and could be uploaded to the snap [https://snapcraft.io/store store] for either public testing or actual release.
This snap is now in a very good shape and could be uploaded to the snap [https://snapcraft.io/store store] for either public testing or actual release.
== Using a Content Snap ==
== Glossary ==
== Glossary ==

Revision as of 13:17, 1 April 2019

Under construction.png
Under Construction
This is a new page, currently under construction!

Want to run your application binaries on any Linux distribution? Snap makes that possible.

For general purpose information about snap, snapcraft and how to use them please have a look at their documentation as it excellently teaches you most generic information about snaps https://docs.snapcraft.io Even so this page will teach you a lot of the basics of snaps.

For a primer on YAML, the format used to describe snap building, have a look here https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html

TBD separate page specifically about how to use the content snap

Under construction.png
Under Construction
This is a new page, currently under construction!

How it Works

Snaps work very much like DMG files on OS X. A snap is a compressed squashfs file containing the entire file tree of the program. A system-level helper called snapd manages the snap file and mounts it into the file system. Snapd also manages host-level integration (e.g. creation of .desktop files). Running an application from the snap needs to go through snapd (e.g. snap run foo) which needs to be installed on the target system. Snap, the format, could be used by various daemon implementations, but as a matter of fact the only viable implementation is snapd and maintained by Canonical. Snapd frowns upon side-loaded snaps. You may still install a snap downloaded manually, but the preferred way to use snaps is through snapd directly which in turn will go to the associated store as a remote source. The store too is run by Canonical. Most aspects of snaps may be inspected/changed through the CLI for snapd. It's simply called "snap" snap help for help.

Binary Sources

Building a snap we'll lovingly call "snapping". At the time of writing you can snapcraft on two core systems: one is Ubuntu 16.04, the other is Ubuntu 18.04. Both of them are the LTS version of Ubuntu and therefore supported for what seems like forever. Snapcraft has native support to pull binary packages (i.e. debs) into the snap so that you might build against them without having to build the binaries yourselves. For example you could use Qt from Ubuntu directly without the need to build it in your snap. However, since the base systems are LTS the software is usually very dated. Seeing as you may need newer dependencies there's a bunch of ways you can get them besides pre-built Ubuntu debs:

As Snapcraft Parts

You can add any number of additional parts that build dependencies. For example you might build your own qtbase as part of snap. How much work this is can be vastly different between software. Building all of Qt can get quickly slow, at the same time relying on an ancient Qt may not be practical either. To gain access to newer foundations software you may instead want to get them ...

From KDE neon

We are in luck and KDE neon already builds packages for Ubuntu LTS, so you may choose to simply use neon debs on top of Ubuntu debs. This gives access to the latest Qt, KDE frameworks and other related libraries. This can be a huge time saver. Unfortunately Snapcraft's support for adding additional repositories is non-existent and so if you choose to go this route you may need to somewhat manually manage the build environment yourself e.g. using an especially prepared LXD container.

From Content Snaps

Content snaps are other snaps you can "include" in your snap to get access to pre-existing binary (or data) assets so you don't need to ship them. Notable advantage is that one content snap may be shared across multiple consumers and thus reduce the disk and network footprint. For example there is a read to use KF5 content snap which you can use to get access to all of KF5 and Qt5. Content snaps may be combined with the other means of sourcing binaries.

From PPAs

Much like KDE neon, this too will require you to manage the build environment manually. Also, when using PPAs beware that they may not be compatible with neon (so, ideally you should use either-or) and that many of them are not particularly trustworthy or well maintained (important vis-a-vis security).


The tool to build snaps is called snapcraft. The definition for how to craft a snap is written down in snapcraft.yaml. Generally speaking a snapcraft.yaml will contain global metadata of the snap, a list of applications provided by the snap, and lastly a list of parts that when put together result in the snap. Access to the host system is controlled through a plug-and-slot system which is also used in the snapcraft.yaml. Each application may have one or multiple plugs it uses to get access to resources of the host system or other snaps. For example the 'desktop' plug gives access to host fonts and icons. Also see https://docs.snapcraft.io/interface-management/6154

Types of Snap

With a broad overview of abilities and shortcomings let's dive right in and look at types of snaps we might build.


A standalone snap is a snap which solely relies on a "core" but no other snaps. This is generally speaking the most reliable type of snap as everything the snap needs is inside the snap (except libc and friends which are in the core).

It is also the best supported way of building a snap since it's been around since the very beginning.


  • Very reliable
  • Easy to build and test
  • You are always on your own and unrelated changes rarely if ever can impair your snap


  • Huge in size (each standalone snap needs to ship their own Qt/l10n and necessary kf5 and other dependencies)
  • You need to take care of setting up your execution environment yourself.
  • You are always on your own and unrelated changes rarely if ever can improve your snap


 1 name: qtnetsample
 2 version: '0'  # the version of the snap. has no semantic meaning
 3 summary: This is my-snap's summary  # 79 char long summary
 4 description: This is my-snap's description  # a longer description for the snap
 5 confinement: strict  # use "strict" to enforce system access only via declared interfaces
 6 grade: devel # use "stable" to assert the snap quality
 7 base: core18 # the core this snap depends on
 9 apps:
10     qtnetsample:
11         command: launcher qtnetsample # the launcher will setup the environment for qtnetsample to find libraries/plugins/data etc
12         plugs: [x11, network, network-bind] # this snap will be able to act as xclient and talk over the network
14 parts:
15     qtnetsample:
16         build-packages: [qt5-default]
17         plugin: cmake
18         stage-packages: [libqt5network5, libqt5core5a]
19         source: .

Shared Snap

A snap may also choose to use one or more Content Snaps (see glossary) to share part of the binaries or UI assets with other snaps. As shared content will generally be in the content snap, the ultimate size of the snap can be fairly small. Think of this as an approach more akin to how traditional binary package dependencies work. Albeit with many of the same complexities surrounding it.

For example KDE neon builds the kde-frameworks-5 content snap. It contains all of Qt and all (not-deprecated) KDE frameworks along with Plasma integration rigging.


  • Application snap is super small
  • You don't need to care of setting up the execution environment
  • Integration and international improvements are all in one place (shared environment setup etc)
  • Generally speaking when using the KF5 content snap SDK you can get access to KDE neon's Qt and Frameworks without having to actually add the deb sources.


  • Up-front "cost" of a single application may be higher. e.g. if the application only uses QtCore, the content snap will still bring in all of Qt and all of KF5 through the content snap. It's like a shared library, the more it is used the smaller the cost per-user.
  • Somewhat harder to build and test because of added complexity. Also managing deb build dependencies in addition to content snap SDKs is problematic TBD link to forum post
  • Unrelated changes in the content snaps may impair your snap
  • Since this type was introduced a while after snap initially came into being you still can feel rough edges when working with content snaps.


 1 ---
 2 name: kbruch
 3 version: 18.12.1
 4 confinement: strict
 5 grade: stable
 6 base: core18
 7 adopt-info: kbruch # part to adopt appstream data from (first in parse list)
 8 apps:
 9     kbruch:
10         command: kf5-launch kbruch
11         plugs:
12         - kde-frameworks-5-plug
13         - home
14         - x11
15         - opengl
16         - network
17         - network-bind
18         - unity7
19         - pulseaudio
20         - desktop
21         - desktop-legacy
22         common-id: org.kde.kbruch.desktop
23         desktop: "usr/share/applications/org.kde.kbruch.desktop"
24 slots:
25     session-dbus-interface:
26         interface: dbus
27         name: org.kde.kbruch
28         bus: session
29 plugs:
30     kde-frameworks-5-plug:
31         content: kde-frameworks-5-core18-all
32         interface: content
33         default-provider: kde-frameworks-5-core18
34         target: kf5 # target directory where the content is mounted i.e. $SNAP/kf5/
35 parts:
36     kbruch:
37         build-snaps:
38         - kde-frameworks-5-core18-sdk
39         after:
40         - kde-frameworks-5-env
41         plugin: cmake
42         source: src
43         configflags:
45         - "-DCMAKE_INSTALL_PREFIX=/usr"
46         - "-DCMAKE_BUILD_TYPE=Release"
47         - "-DENABLE_TESTING=OFF"
48         - "-DBUILD_TESTING=OFF"
50         parse-info: [usr/share/metainfo/org.kde.kbruch.appdata.xml]
51     kde-frameworks-5-env:
52         plugin: dump
53         source: https://github.com/apachelogger/kf5-snap-env.git

Execution Environment and Launchers

When binaries inside snaps get executed they only get a super minimal environment set up by snapd. The snap itself needs to take care of most of the higher level spin up of the environment.

Inside a confined snap the / will be the core snap, while the actual snap will be in SNAP=/snap/name/rev/.... As a result for example icons, which usually would be expected in $XDG_DATA_DIRS/icons meaning /usr/share/icons, will need to actually be looked for in $SNAP/usr/share/icons. The same applies to pretty much all XDG_* variables, LD_LIBRARY_PATH, various QT_* variables and so on and so forth.

Simply put: a snap's tree is not "merged" with the core's tree, rather it is "mounted" inside the core tree under $SNAP and so each snap needs to set up an environment which redirects or adds $SNAP to all lookup locations you can possibly imagine. As general assumptions about where things are on a Linux system no longer hold true. One the one hand that technically allows you to create a snap which entirely does away with the FHS, on the other it means someone needs to actually mangle the environment so files may be located properly.

That's why most, if not all, desktop application snaps will need a launch helper. The launcher will set up all the general purpose path variables so they point to $SNAP. A standard desktop launcher implementation is available here https://github.com/ubuntu/snapcraft-desktop-helpers. Obviously you can also write your own, but since there are lots of things to consider, even for simple applications, it's probably not a good idea to do so.

You can have a look at the standard environment by running

snap install hello-world
snap run --shell hello-world

This will drop you on a minimal shell inside the confined snap, where you can have a look around to see what the snap sees.

A Snap from Scratch

We'll create a snap bundle from scratch using LXD, the KDE neon repositories, and will also look at how to make use of the KDE Frameworks 5 content snap. Using LXD and managing the environment manually allows us to use the KDE neon repositories, it does however also mean that we need to take care of more things ourselves. It also means that snapcraft will need to be run with --destructive-mode to instruct it that it may install dependencies and the like into the actual system.

To follow along you'll need a working LXD setup. A KDE neon VM would do as well. Docker however is pretty unsuitable as we need a working systemd, which is hard to get with docker. To get started with LXD, you need to run lxd init on most distributions.

sudo lxc launch --ephemeral ubuntu:18.04 mycontainer # start an ephemeral container. it will be deleted once stopped
sudo lxc exec mycontainer -- bash

You are now inside an Ubuntu 18.04 container. We'll continue to setup the neon repositories and the latest stable snapcraft.

apt-key adv --keyserver keyserver.ubuntu.com --recv E6D4736255751E5D
echo 'deb http://archive.neon.kde.org/unstable bionic main' > /etc/apt/sources.list.d/neon.list
apt update
snap install --stable --classic snapcraft
mkdir /workspace
cd /workspace

Now we can start writing our snapcraft.yaml. You can either install a command line editor and write it inside the container or write it on your system and "upload" it to the container with the command sudo lxc file push --recursive snapcraft.yaml mycontainer/workspace/. Let's start with the absolutely bare minimum.

 1 ---
 2 name: kmplot
 3 version: '0'
 4 summary: Function Plotter
 5 description: KmPlot is a program to plot graphs of functions.
 6 confinement: strict
 7 grade: stable
 8 base: core18
10 parts:
11     kmplot:
12         plugin: cmake
13         source: https://anongit.kde.org/kmplot.git
14         configflags: ['-DCMAKE_INSTALL_PREFIX=/usr']

We've defined (not very good) metadata for the snap and a single part to build. Attempting to build this using snapcraft --destructive-mode will however result in an error similar to

CMake Error at CMakeLists.txt:1 (project):
  No CMAKE_CXX_COMPILER could be found.

We haven't installed any of our build dependencies. An easy fix. We'll simply add build-packages to our part. In this case the compiler is missing and it's usually best pulled in via the package "build-essential". You'd continue building your build-packages list until the software starts building. Fortunately I already know all the stuff that is needed so we can move ahead.

For software which is packaged through KDE neon (which is just about everything KDE) you can get a good list to start with by looking at the debian/control file of the Neon/release branch of the packaging repository at https://packaging.neon.kde.org

The part needs editing with build-packges specified before we can do another snapcraft run:

1 parts:
2     kmplot:
3         plugin: cmake
4         source: https://anongit.kde.org/kmplot.git
5         source-branch: Applications/19.04 # not needed for master
6         configflags: ['-DCMAKE_INSTALL_PREFIX=/usr']
7         build-packages: [build-essential, extra-cmake-modules, libkf5widgetsaddons-dev, libqt5svg5-dev, libkf5parts-dev, libkf5doctools-dev, libkf5crash-dev, gettext]

Snapcrafting our refined snapcraft.yaml should finally succeed in creating a snap. Unfortunately it will also print a long list of missing dependencies:

Staging kmplot 
Priming kmplot 
The 'kmplot' part needs the following libraries that are not included in the snap or base: 
These dependencies can be satisfied via more stage-packages, more parts, or content sharing.
Snapping 'kmplot' |                                                                                                                                  
Snapped kmplot_18.12.1_amd64.snap

We can build the software fine, but snapcraft is concerned that we haven't "snapped" all the necessary dependencies. The list it prints is by no means exhaustive, it's only things snapcraft can easily detect, such as missing shared libraries. Getting the necessary dependencies on board is a bit tricky. The easiest way would be to simply take the list of build-packages and use the exact same list as stage-packages. Stage packages (and their dependencies) get put into the final snap. So, by using the build-packages also as stage-packages we'd put a whole bunch of buildtime-only stuff into our final snap unless we explicitly exclude files from getting primed. Since that is somewhat unreliable and probably not particularly advisable unless you have a firm grasp of all concepts involved, we'll opt to do it the other way around and only stage packages we know are need. So from the list of build-packages packages we'll simply look at their dependencies and try to infer which of their dependencies we need (if any).

  • build-essential we'll leave out entirely, as the name suggests it only contains buildtime stuff such as make and gcc
  • extra-cmake-modules similarly is only useful at build time as it contains cmake extensions
  • libkf5widgetsaddons-dev is a dev package of a library and thus actually needed at runtime.

We'll inspect its package relationships with the command apt show libkf5widgetsaddons-dev | grep -P "(Depends|Recommends)".

Depends: libkf5widgetsaddons5 (= 5.56.0+p18.04+git20190322.0124-0), qtbase5-dev (>= 5.8.0~)
Recommends: libkf5widgetsaddons-doc (= 5.56.0+p18.04+git20190322.0124-0)

We can ignore qtbase5, its another dev package. libkf5widgetsaddons-doc is library documentation which we also do not need. libkf5widgetsaddons5 is the actual library and we'll definitely want it staged. We'll continue this review for all build-packages:

  • libqt5svg5-dev: libray is libqt5svg5
  • libkf5parts-dev: library is libkf5parts5
  • libkf5doctools-dev: buildtime only, builds documentation
  • gettext: buildtime only, builds localization
  • libkf5crash-dev: library is libkf5crash5

We now have a list of packages that need staging and can update our part accordingly:

1 parts:
2     kmplot:
3         plugin: cmake
4         source: https://anongit.kde.org/kmplot.git
5         source-branch: Applications/19.04 # not needed for master
6         configflags: ['-DCMAKE_INSTALL_PREFIX=/usr']
7         build-packages: [build-essential, extra-cmake-modules, libkf5widgetsaddons-dev, libqt5svg5-dev, libkf5parts-dev, libkf5doctools-dev, libkf5crash-dev, gettext]
8         stage-packages: [libkf5widgetsaddons5, libqt5svg5, libkf5parts5, libkf5crash5]

Snapcrafting our refined data should now create a snap without any additional warnings. This should be good enough to now. You can pull the snap out of the container with sudo lxc file pull mycontainer/workspace/kmplot_0_amd64.snap . and install it into with snap install --force-dangerous kmplot_0_amd64.snap and try to run it snap run kmplot. Unsuccessfully...

error: cannot find app "kmplot" in "kmplot"

Before snapd can run an application the snap first needs to declare one. Let's add one:

1 apps:
2     kmplot:
3         command: kmplot
4         plugs: [x11, opengl, desktop, desktop-legacy]

Plugs are a bit out of scope, for more information on them refer to the upstream snapcraft documentation. Snapcrafting, installing and running the new snap will unfortunately still result in problems:

kmplot(4481)/(qt.qpa.plugin) unknown: Could not find the Qt platform plugin "xcb" in ""
kmplot(4481)/(default) unknown: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this proble

This is where the environment helpers come in. Qt attempts to find the xcb plugin in /usr/... but actually needs to look in $SNAP/usr/... Easiest solution is using the kf5-launch helper. We need to define a new part for it. It doesn't have any build system so we simply use the 'dump' plugin which copies the source tree verbatim into the snap. One caveat is that we need to skip the kf5 directory, otherwise the launcher thinks we want to use it with the KF5 content snap. To skip directories or files in one of the stage or prime lists simply prefix it with a minus character:

1 parts:
2     [...]
3     kde-frameworks-5-env:
4         plugin: dump
5         source: https://github.com/apachelogger/kf5-snap-env.git
6         stage: ['-kf5/'] # keeps it out of

snapcraft and install again and you should see some progress:

kmplot(8069)/(default) unknown: "Couldn't register name 'org.kde.kmplot-8069' with DBUS - another process owns it already!"

Many of our applications will expose themselves on the dbus session bus. Doing so does require extra permissions though. The snap needs a dbus slot. A dbus slot allows us to claim a well-known name on the session bus, meaning snapd will allow us to register a service on it. In our case the name is org.kde.kmplot and snapd will be smart enough to figure out that this name also entails our per-process variants org.kde.kmplot-$PID. To define a slot we'll need a completely new section in our snapcraft.yaml:

1 slots:
2     session-dbus-interface: # semi-arbitrary name
3         interface: dbus # type of the interface; this allows snapd to restrict/allow what is necessary
4         name: org.kde.kmplot
5         bus: session

With this the application should now be actually starting. Alas, it looks terrible! We haven't yet added any styles or icons! Let's solve this. We can either use a new part of extend our kmplot. For easier reading we'll use a new part, in practice that is not really necessary though.

1 parts:
2     [...]
3     plasma-integration:
4         plugin: nil
5         stage-packages: [plasma-integration] # this also pulls in all of breeze, so it forms a complete theme set

Snapcraft and install and the application should look like a piece of art! In fact, it's almost ready for production now. We are still missing a bunch of metadata.

  1. Desktop file (so snapd can shove us into the host's XDG menu)
  2. Icon file for snap store
  3. Appstream association, so discover can find the snap

Since we can derive all of this from appstream data we'll start by extending our kmplot part to parse the appstream file by setting the 'parse-info' attribute:

 1 parts:
 2     [...]
 3     kmplot:
 4         plugin: cmake
 5         source: https://anongit.kde.org/kmplot.git
 6         source-branch: Applications/19.04 # not needed for master
 7         configflags: ['-DCMAKE_INSTALL_PREFIX=/usr']
 8         build-packages: [build-essential, extra-cmake-modules, libkf5widgetsaddons-dev, libqt5svg5-dev, libkf5parts-dev, libkf5doctools-dev, libkf5crash-dev, gettext]
 9         stage-packages: [libkf5widgetsaddons5, libqt5svg5, libkf5parts5, libkf5crash5]
10         parse-info: [usr/share/metainfo/org.kde.kmplot.appdata.xml]

From this we can let our app automatically determine the desktop file and also hint the appstream id to discover (appstream id is called common-id in snap):

1 apps:
2     kmplot:
3         command: kmplot
4         plugs: [x11, opengl, desktop, desktop-legacy]
5         common-id: org.kde.kmplot.desktop

And lastly we can drop our summary and description fields in favor of adopting the information from the parsed appstream data of our kmplot part. The entire refined snapcraft.yaml should now look something like this:

 1 ---
 2 name: kmplot
 3 version: '0'
 4 confinement: strict
 5 grade: stable
 6 base: core18
 7 adopt-info: kmplot # part to adopt from (first in parse list)
 9 apps:
10     kmplot:
11         command: kf5-launch kmplot
12         plugs: [x11, opengl, desktop, desktop-legacy]
13         common-id: org.kde.kmplot.desktop
15 slots:
16     session-dbus-interface: # semi-arbitrary name
17         interface: dbus # type of the interface; this allows snapd to restrict/allow what is necessary
18         name: org.kde.kmplot
19         bus: session
21 parts:
22     kmplot:
23         plugin: cmake
24         source: https://anongit.kde.org/kmplot.git
25         source-branch: Applications/19.04 # not needed for master
26         configflags: ['-DCMAKE_INSTALL_PREFIX=/usr']
27         build-packages: [build-essential, extra-cmake-modules, libkf5widgetsaddons-dev, libqt5svg5-dev, libkf5parts-dev, libkf5doctools-dev, libkf5crash-dev, gettext]
28         stage-packages: [libkf5widgetsaddons5, libqt5svg5, libkf5parts5, libkf5crash5]
29         parse-info: [usr/share/metainfo/org.kde.kmplot.appdata.xml]
30     kde-frameworks-5-env:
31         plugin: dump
32         source: https://github.com/apachelogger/kf5-snap-env.git
33         source-branch: standalone
34         stage: ['-kf5/']
35     plasma-integration:
36         plugin: nil
37         stage-packages: [plasma-integration] # this also pulls in all of breeze

Before you run snapcraft this time, make sure to clean up everything rm -r prime stage parts. Appstream extraction strings across multiple stages, so you'll need a fairly clean build to actually pick up the data. After installation you should find kmplot listed in your menu and having an icon.

This snap is now in a very good shape and could be uploaded to the snap store for either public testing or actual release.

Using a Content Snap

Under construction.png
Under Construction
This is a new page, currently under construction!


Words you'll hear and not know what they mean:

  • snap: The actual bundle format.
  • snapd: The daemon that manages snap on a system.
  • snapcraft: The build tool for building a snap.
  • 'app: In the context of snapcraft/snapd this is the (portable) description of an 'executable' exposed to the outside (i.e. something snapd knows how to run).
  • parts: In the context of snapcraft a part refers to one build entity. They describe where to get the source of the entity, how to build it, how to stage it into the final snap and which other parts are a dependency and need to be built first. A part is much like a "makefile" target.
  • interfaces: A way for a snap to talk to the outside world (or another snaps). Split into slots and plugs. Each of which has their own security permissions as a client may need to be able to do different things from a server. https://docs.snapcraft.io/interface-management
  • slot: The provider part of an interface. e.g. a kwin snap might have a wayland-client slot which exposes a way for clients to talk to kwin.
  • plug: The client part of an interface. e.g. an application may plug into the wayland-client slot of kwin to talk to it.
  • Core: A special snap containing the core aspects of any Linux OS (libc/libpthread/...). All snaps depend on exactly one core which provides the snap's understanding of what will be in "/" from the snap's POV. The core does not include a kernel! Kernels may be snaps.
  • Content Snap: Special kind of snap that implements the "content" interface. It's kind of like a shared dependency between snaps allowing one snap to be bound into the scope of another snap. For example the KF5 content snap may be used to share all of KF5 across multiple snaps.
  • Build Snap: Also a special kind of snap, it's the build-time variant of the Content Snap and contains header files etc. necessary to build against a Content Snap.
  • stage, staging: As part of snapcrafting parts get "staged". This kind of means the same as make install, but it's actually a separate step after make install. For the process of staging, snapcraft will copy all files created by make install into a stage directory. You may also exclude certain files or reorganize the files (e.g. rename, or move to different directory). The stage is available for parts ordered after the current one, meaning that they for example can link against a newly built library.
  • prime, priming: Is similar to staging but happens once all parts are built and staged. Priming is the process by which the snap tree is actually constructed. Priming, like staging, allows for excluding files (e.g. dev headers may be staged so other parts can build using them but later excluded from priming and thus left out of the final bundle).

This page was last edited on 1 April 2019, at 13:17. Content is available under Creative Commons License SA 4.0 unless otherwise noted.