Using snaps for distribution on Linux
- mcphail
-
Topic Author
- Zombieman
-
Less
More
- Posts: 1
6 years 6 months ago #1
by mcphail
Using snaps for distribution on Linux was created by mcphail
I wonder if you'd be interested in looking at snaps as a distribution method for your creations on Linux? The snap package format is fully supported on Ubuntu (by far the most popular Linux distribution) and Solus, and with partial support on many other distributions.
Information about the snap format can be found at snapcraft.io . Snaps are an attractive format for several reasons:
Lets look at these points, one at a time.
They are easy to build
Have a look at my repository for a Blade of Agony snap . It contains a launcher script, an icon, a .desktop file and a yaml file describing how to build and bundle BOA from git, gzdoom from git, the iwad from freedoom and all the supporting libraries. This repository is linked to the snapcraft build service . Every commit to this repository will trigger the build service to make a snap package with all of these components for 64bit, 32bit and ARM architectures. Any users subscribed to the "edge" (most unstable) channel of my "boa" project will immediately receive a binary delta download, updating them to the latest version. If that version is useful, it can be promoted all the way up to the "stable" channel, where it will appear in the snap store for Mr(s) Average to download.
From your point of view, all that is required is a push to github to trigger this whole build-and-release process. Promoting a good build to the store takes just a couple of extra terminal commands.
Whilst my "snapcraft.yaml" file resides in a separate github repository, with some minor tweaking it could be included in your own repo and linked to the build service. Thus, each and every push to your own repository would trigger a build on the Canonical servers and would be rolled out to those crazy users and developers on the "edge" channel. What could be more simple?
They are secure
On Ubuntu and Solus, snaps run in a fully confined environment. Basically, that means they can't access parts of the filesystem and hardware unless they have appropriate permissions. If you make a mistake in your mods, you would not be able to cause damage to unrelated parts of the user's filesystem. If there is a security flaw in your mod or gzdoom, an attacker would only be able to access or damage the game files.
Other Linux distributions which support snaps don't have full confinement yet. Hopefully that will come in time.
This does cause problems, however. For example, gzdoom will not run in a confined environment because it insists on writing to the .config directory in the user's home directory. It can't get access to that under confinement. For the time being, my boa snap uses a patched version of gzdoom to avoid this problem. In the longer term, I'd hope I could persuade upstream gzdoom to change this behaviour.
They automatically update on the user's machine
Snaps automatically update by binary deltas. The initial snap download for BOA, gzdoom, the iwad and libraries is nearly 500MB. Each small update will only download a few megabytes. Users on the "edge" channel can always have the latest-and-greatest version of your mod without downloading hundreds of megabytes each time. Users on the "stable" channel can get releases as soon as you release them.
They are ideal for bundling dependencies
Simple tweaks of the snapcraft.yaml file can build the newest versions of your mod and gzdoom, or specific git commits, tags or branches. All the supporting libraries are there and installed by default.
They can be hosted on the snap store
All of this can happen on github and Canonical's servers. You don't have to host anything new.
To try my work-in-progress snap of BOA on Ubuntu, run
. If I release a stable version, it can be installed by
, via the Ubuntu?GNOME software centre or at
the snap store page
(which will not exist until I make a stable release).
---
What do you think?
Information about the snap format can be found at snapcraft.io . Snaps are an attractive format for several reasons:
- They are easy to build.
- They are secure.
- They automatically update on user's machines
- They are ideal for bundling dependencies
- They can be hosted on the official snap store. This is hosted by Canonical, which means they don't eat your bandwidth allowance
Lets look at these points, one at a time.
They are easy to build
Have a look at my repository for a Blade of Agony snap . It contains a launcher script, an icon, a .desktop file and a yaml file describing how to build and bundle BOA from git, gzdoom from git, the iwad from freedoom and all the supporting libraries. This repository is linked to the snapcraft build service . Every commit to this repository will trigger the build service to make a snap package with all of these components for 64bit, 32bit and ARM architectures. Any users subscribed to the "edge" (most unstable) channel of my "boa" project will immediately receive a binary delta download, updating them to the latest version. If that version is useful, it can be promoted all the way up to the "stable" channel, where it will appear in the snap store for Mr(s) Average to download.
From your point of view, all that is required is a push to github to trigger this whole build-and-release process. Promoting a good build to the store takes just a couple of extra terminal commands.
Whilst my "snapcraft.yaml" file resides in a separate github repository, with some minor tweaking it could be included in your own repo and linked to the build service. Thus, each and every push to your own repository would trigger a build on the Canonical servers and would be rolled out to those crazy users and developers on the "edge" channel. What could be more simple?
They are secure
On Ubuntu and Solus, snaps run in a fully confined environment. Basically, that means they can't access parts of the filesystem and hardware unless they have appropriate permissions. If you make a mistake in your mods, you would not be able to cause damage to unrelated parts of the user's filesystem. If there is a security flaw in your mod or gzdoom, an attacker would only be able to access or damage the game files.
Other Linux distributions which support snaps don't have full confinement yet. Hopefully that will come in time.
This does cause problems, however. For example, gzdoom will not run in a confined environment because it insists on writing to the .config directory in the user's home directory. It can't get access to that under confinement. For the time being, my boa snap uses a patched version of gzdoom to avoid this problem. In the longer term, I'd hope I could persuade upstream gzdoom to change this behaviour.
They automatically update on the user's machine
Snaps automatically update by binary deltas. The initial snap download for BOA, gzdoom, the iwad and libraries is nearly 500MB. Each small update will only download a few megabytes. Users on the "edge" channel can always have the latest-and-greatest version of your mod without downloading hundreds of megabytes each time. Users on the "stable" channel can get releases as soon as you release them.
They are ideal for bundling dependencies
Simple tweaks of the snapcraft.yaml file can build the newest versions of your mod and gzdoom, or specific git commits, tags or branches. All the supporting libraries are there and installed by default.
They can be hosted on the snap store
All of this can happen on github and Canonical's servers. You don't have to host anything new.
To try my work-in-progress snap of BOA on Ubuntu, run
Code:
sudo snap install --edge boa
Code:
sudo snap install boa
---
What do you think?
Please Log in or Create an account to join the conversation.