I have had seen startup issues with snap packages and it seems with the new LZO compression, those issues are fixed.
I manually tried to build telegram-desktop to verify. I also did a “before-after” of the Chromium snap from Canonical and in both cases my issues are resolved.
Now comes the real question, what would be the right time to start proposing upstream of different snaps to start using LZO compression. What would happen if an unsupported version of snapd is installed, will the software stop working at all ?
SIDENOTE: I should also highlight that there are also cases where LZO compression doesn’t really improve anything, at least on reasonably “powerful” PCs, but I’d assume the results on a low power, slow IO device like a RaspberryPi will likely be better.
I think what you mean is what happens if the installed version of snapd doesn’t support LZO compression and someone installs a snap that uses LZO? The TLDR is that snapd doesn’t actually care about what format of compression the snap is in - only the store and kernel really cares.
In reality, snapd only cares about the compression format of the snap when it is creating the snap file, that is at build time with snap pack. The rest of the time, snapd treats it as a binary blob downloaded from the store, and instructs systemd to mount the .snap file, and systemd itself relies on the kernel to mount the snap. The only exception to this (and was in fact one of the bugs that we had to fix for 2.47.1 before LZO was allowed to be readily available), is inside container environments where the container is not allowed to mount things via the kernel and instead uses a FUSE (filesystem in userspace) implementation - that FUSE implementation must support mounting LZO compressed squashfs files. We had a bug in Ubuntu LXD containers where the snapfuse (which is just a fork of squashfuse but for snaps) wasn’t being built with LZO support so it didn’t support mounting LZO snaps inside lxd containers, but we have fixed this.
