Is there Feature Parity between Snap and Apt releases?

On my Ubuntu 18.04 machine, I am currently using LXD 3.4, installed through Snap. As I encounter problems mounting sockets from /run and /tmp paths (see, I would like to install LXD 3.4 through Apt.

The default Apt package for LXD on Ubuntu 18.04 is currently 3.0.1-0ubuntu1~18.04.1. Though, there is a newer package available too, namely 3.0.2-0ubuntu3, which was created about two weeks ago.

I am just wondering, although unlikely, that the Apt package 3.0.2-0ubuntu3 has the same features as the LXD Snap 3.4?

If this is not the case, is there a way of installing LXD 3.4 through Apt?

1 Like

LXD roughly follows semantic versioning (except that till now backward compatibility has been also maintained between major releases, e.g. 2 to 3), so 3.0 has fewer features that 3.4, and 3.0.1 has the same features as 3.0.2, differing only in bug fixes.

The features introduced in a release are highlighted in the release notes.

There’s no official APT package for 3.4. All new versions of LXD after 3.0.x are snap-only, and 3.0.x only gets bug fixes.

Is this going to the be way forward? Snaps appear to be a desktop-focused distribution means to help developers and not meant for the datacenter. Will there be no more Apt builds for Ubuntu Server? That is terribly unfortunate if not and will certainly limit adoption in corporate server rooms.

It is ironic since snaps initially were supposed to be packages for IoT, Ubuntu Core and other security-concious environments.

It is true that newer features are available to the snap package of LXD. Also, live migration for the snap LXD has to be enabled manually as it may not work fully as well as with the Deb package.
LXD 3.0.1 is quite usable for server environments that need bugfix support for five years and fewer changes.

CRIU works as well in the snap as it does the deb these days, the problem is that it just doesn’t work well in general. So for the deb, you need to install the criu package separately, for the snap, you need to set the flag to enable the built-in criu.

It’s really mostly about shielding people from confusing CRIU failures when they didn’t actually intend to perform a live migration.