This is a bit of a dayjob post, but as I maintain a bunch of snaps in my own time, I figured it’s not out of place here.
Typically when I (or indeed any developer) uses
snapcraft to build a snap, a
snapcraft.yaml drives the process. I’ll integrate some kind of CI or build system, and start publishing to the Snap Store. Usually, once created, the yaml doesn’t need much in the way of changes. Back when we first started building snaps, we were using Ubuntu 16.04 LTS systems. At runtime the snap would leverage the
core snap is a super minimal Ubuntu 16.04 LTS runtime environment.
Since then we’ve had releases of
core18 based on Ubuntu 18.04 LTS and more recently,
core20 based off Ubuntu 20.04 LTS. The observant will note the original base
core isn’t called
core16 which is a shame, but hey-ho. In the early days it wasn’t necessary to specify a
base in the
snapcraft.yaml because it was assumed to always be
core. Indeed I don’t think early releases of
snapcraft even had a
snapcraft has been re-engineered and restructured such that specifying
base makes it behave differently than if you don’t specify one at all. Effectively not specifying a
base gives backwards-compatibility so existing snaps continue to build. However the newer features and optimisations that land in
snapcraft are only in the codepath where a
base is specified.
So to get access to these juicy features, we reccommend developers migrate their snaps from not specifying a base, to specifying one, specifically one newer than Ubuntu 16.04 LTS. Specifying a newer
core20 means that as well as newer
snapcraft, the publisher also gets access to updated packages from the Ubuntu 18.04 or 20.04 archives.
Sadly it’s not just a case of adding
base: core20 and you’re done. There’s a few other things that need adjusting. We’re working on comprehensive documentation to cover all of the.. uh.. bases, but below you’ll find a taster.
I noticed the cointop snap wasn’t using a
base. By “noticed”, I grepped:
alan@robot:~$ snap install cointop cointop 0a0530d from Miguel Mota (miguelmota) installed alan@robot:~$ grep ^base /snap/cointop/current/meta/snap.yaml alan@robot:~$
base found implies
core which is Ubuntu 16.04 LTS based, as mentioned earlier. So what did I do to update it? Here’s the diff.
-version: master -version-script: git -C parts/cointop/build rev-parse --short HEAD +adopt-info: cointop summary: Interactive terminal based UI application for tracking cryptocurrencies description: | cointop is a fast and lightweight interactive terminal based UI application for tracking and monitoring cryptocurrency coin stats in real-time. grade: stable confinement: strict +base: core20 parts: - go: - source-tag: go1.14 cointop: - after: [go] source: . plugin: go - go-importpath: github.com/miguelmota/cointop + build-packages: + - git + override-pull: | + snapcraftctl pull + snapcraftctl set-version $(git rev-parse --short HEAD) apps: cointop: - command: cointop + command: bin/cointop plugs: - network - network-bind
Let’s break it down!
version-script option is deprecated, replaced by
snapcraftctl set-version inside the
-version: master -version-script: git -C parts/cointop/build rev-parse --short HEAD +adopt-info: cointop
override-pull is a series of commands which can be run to override the pull stage of the
snapcraft lifecycle. Here we yoink the git revision and use that as the version number on the built snap.
+ override-pull: | + snapcraftctl pull + snapcraftctl set-version $(git rev-parse --short HEAD)
go plugin pulls in a newer golang, so we don’t need to have a separate part which forces us to get a newer
go binary than shipped in Ubuntu 16.04 LTS. Further, the
go-importpath is no longer required, simplifying this section.
- go: - source-tag: go1.14 cointop: - after: [go] source: . plugin: go - go-importpath: github.com/miguelmota/cointop
Somehow the old version of
snapcraft or maybe the
go part was pulling in a
git binary from somewhere. We try not to automagically do stuff that is unexpected. So I need to be explicit that we need the
git build package as part of the build. So I added that.
+ build-packages: + - git
snapcraft code-path is more strict on explicitly specifying binary locations in the
apps section. As the
cointop binary ends up in
$SNAP/bin we just need to prepend
bin/ to solve this.
- command: cointop + command: bin/cointop
Oh, and we need to actually add the new
That’s it. I submitted this as a pr on the upstream project.
Other snaps will certainly require more invasive changes, but I thought this would be a good example of a simple snap which only needed a few updates to bring it up to spec.