Why only snap packages?

I didn’t find an immediate answer to this question and wondered about this for a long time now.
Why the decision to only publish snap packages? With deb packages I never had a problem but snap, where do I begin …

  • Auto updates break the systems on a regular basis
  • Where are the logs found again?
  • $HOME not in /home/$USER … (╯°□°)╯︵ ┻━┻
    Not that it was my decision to change this, but if you are lucky enough to get a company supported linux env, those are the things you have to deal with.
  • As lxd uses a global database downgrades are not possible anyway, so no need to use multiple versions

My point is, I :heart: to use lxd and it’s a fantastic piece of work. However, snap sometimes makes it barely usable.

I know there are some deb packaging efforts going on: https://github.com/el-eks-di/lxd-deb
But why not again an official deb package?

1 Like

Someone from the team may awnser (as they have lots of times before) but the summary is;

  • Much easier to deploy to various platforms / OS
    • Who wants to create something for every package manager, time consuming :zzz:
  • Ease of debugging (consistent commands the LXD team can drop across all OS’s)
  • Ease of controlling dependencies (as they are isolated)
  • Some crude metrics as part of the snap store
1 Like

The metrics point really doesn’t matter, we almost never look at those, we get far better metrics from image downloads.

The rest is all correct. We welcome other packages and many distributions have very good maintainers publishing native packages for their distro. So far nobody stepped up to maintain a reliable PPA or similar deb archive for Debian/Ubuntu.

As far as upstream is concerned, packaging can take a LOT of time and we’d much rather spend our time developing LXD itself. The snap package gives us something which:

  • Works on many distributions and versions of those distros (biggest bang for the buck)
  • Can be very quickly updated (no multi-week red tape as happens for most native packages on common distributions, pretty useful when you release monthly)
  • Complete control of all our dependencies (makes testing and handling support requests pretty easy)

So from an upstream point of view, it’s a pretty ideal tool and allows us reaching users on distributions we’ve never even heard of without having to put a single extra minute of work on our side.

1 Like

This are all valid arguments the big draw back I see is that currently the end user experience of snap is awful. I basically don’t build new things on LXD because of snap.

Let’s hope snap gets better I guess. :smiley: or someone has time to package LXD for debian/ubuntu

1 Like

Sure, snap makes it easy for developers to deploy and easy for users to find applications.

This convenience comes at a cost:

  • server side proprietary code
  • centralized authority

There is more, but other disadvantages are rather technical. These should be twisting your guts though. What I hear from you, is that you appreciate the convenience that snap gives you. If you follow the argumentation of convenience you’ll end up with a system that is neither free for users nor for developers.

Snap is not even open source.

Someone invented the analogy of a wild animal discovering a cage with a piece of cake inside. The cage would be snap, the cake is convenience and the wild animal is you. Chances are that you’re willingly going to hop behind the bars to enjoy the soothing rush of sugar before you notice that the cage door closes.

Anyways, enjoy your cake. I rather want to live in a world where wild animals are wild and open source software is open source.

1 Like

There indeed is some inconvenience.
But as you said, we all want the cake :slight_smile:

That argument is always a bit of a weak one to me.
We rely on the snap store as a blob delivery mechanism, much like any of the very many CDNs out there.

The bits that matter:

  • LXD itself
  • Snap packaging
  • Snap build tooling
  • The tool that installs the snap

Are all open source and all build operations happen in the open.
The only bit that’s not is the part that takes that .snap squashfs we produce and distributes it so you can quickly download it on your machine.

You can totally go to lxd-latest-candidate : Snap packages : “Ubuntu containers team” team and download the .snap file directly, then install it with snap install.
Or you can checksum it to make sure the store gives you the exact same file we built.

Really doesn’t feel any different than using Github for code hosting. We produce the bits, we sign them and they’re just being distributed verbatim to others at no cost to us, effectively free specialized CDN.

Or you can build LXD yourself, or build the snap yourself or build whatever package you want yourself, all fine with us :slight_smile:

3 Likes