4 ms·
Indeed, we have major issues with snap (doesn't work with $HOME on nfs, and auto updates with very few controls are a terrible idea on servers) so avoid anythin
by davb 6y ago
Indeed, we have major issues with snap (doesn't work with $HOME on nfs, and auto updates with very few controls are a terrible idea on servers) so avoid anything dependent on it. Otherwise, I really like the concept.
- kwk1 6y agoIt's unfortunate that the effort to get LXD packaged natively in Debian [1] seem to have stalled as this is definitely one of the last remaining drawbacks for me. For example, when LXD was still available as a .deb from upstream, it was possible to run LXD inside a container and do nesting, but with the snap, that isn't possible anymore. (However it is now with the --vm flag, though that's really a different mechanism.) As I understand it the big remaining difficulty is dqlite. [1] https://wiki.debian.org/LXD https://wiki.debian.org/LXD
- Foxboron 6y agoI did write a bit about my experience packaging LXD for Arch Linux a while back. I got a ping from a Debian dev telling me the Debian dev working on LXD enjoyed the article, and has been trying to pick up on the work again. The linked wiki page is the outdated one. https://linderud.dev/blog/packaging-lxd-for-arch-linux/ https://linderud.dev/blog/packaging-lxd-for-arch-linux/
- alicemaz 6y agoit's packaged for void, though I'm not sure what that entails. will say it works well enough I didn't find out about the snap mess until I tried to install it on another distro later
- Foxboron 6y agoDebian has stricter rules regarding packaging and vendoring dependencies. Void and Arch packages LXD in a similar fashion by separating all the C dependencies. However, none of us actually separate out the different Go dependencies, they are all vendored inside the LXD package. Debian separates out all of these into own packages.