A benefit of Snapcraft is that typically a developer can configure the packaging definition once, and not have to update it for a long time. Snapcraft will keep cranking out releases, via CI or another build system.
Software moves on though. It pays to re-visit snaps which were developed and published a while back, to see what improvements can be incorporated. Let’s take a look at one update which can reap benefits.
In the beginning
Snapcraft was originally conceived and built around Ubuntu 15.04 and stablised during the time of Ubuntu 16.04 LTS (Long Term Support). Some assumptions are made at build-time that software would compile on an Ubuntu 16.04 LTS system. At runtime, the core snap would be leveraged as a lean base on which to execute.
When Ubuntu 18.04 LTS was released, a newer core18 base was published, and the base keyword introduced into the snapcraft.yaml syntax. Snap publishers could now specify the following in their yaml:
Moving on up
Snapcraft has been updated and improved over the years. Some snap publishers are still using the functional, but legacy, Snapcraft 2.x branch to build. All the recent improvements have been happening in the newer 3.x branch of Snapcraft.
This instructed Snapcraft to use an Ubuntu 18.04 LTS container or Virtual Machine (VM), to target a core18 runtime environment on package installation. Further, there is now a core20 base, which is built from Ubuntu 20.04 LTS.
There are broadly two main side-effects of adding this base parameter to the snapcraft.yaml. First, at build-time a publisher will have access to newer packages from the Ubuntu 18.04 LTS archive. That includes newer compilers and libraries, along with all the other updated and fresh packages, which come with an updated Ubuntu release.
Secondly, specifying base will switch Snapcraft itself to the newer, non-legacy codepath. A ton of new features have arrived in Snapcraft since 3.x (and hence the base keyword) landed.
This includes new methods to use Multipass or LXD to build in VMs and containers. Further, it adds the –destructive-mode to Snapcraft, which is useful in ephemeral CI systems and where nested VMs & containers are not desired.
For developers packaging desktop software, the newer releases of Snapcraft also feature extensions. These make the snapcraft.yaml smaller and simpler, taking some of the guesswork out of packaging graphical desktop applications. They also include optimisations to improve start-up speed, and reduce the resulting snap size dramatically.
In some cases, migrating to the newer Snapcraft codebase is as simple as adding the base: core18 or base: core20 line in the snapcraft.yaml. However there have been some changes to the yaml syntax, and a few features have changed behaviour. So it may take a little more time and yaml changes to effectively update the base.
Updates in depth
Next week we will follow up with a more detailed look at all the new features and updates publishers need to take care of in the migration. In the meantime, take a look at this personal blog post I wrote, “Updating Snap Bases” highlighting one simple example, and more background on the reasoning.
Photo by Tim Gouw on Unsplash