Yesterday I tried to change the Icon= field of a .desktop file in my snap to a symbolic reference, this functionality has been in snap for the past year and a ~half. After doing some testing on my end, everything looked good.
The next day I woke up and immediately realised that Debian and other distributions exist (Programmer dreams are sure weird huh), and snapd itself is fragmented. While Debian can make use of re-exec support, it’s default snapd is 2.38, and I’ve recieved bug reports from people who don’t install core or snapd to make use of re-exec to begin with. Solus is currently 2.39 and can’t make use of re-exec support. I’m sure there’s a lot of other distributions held quite far back, but regardless, there’s substantial userbases of snap who are on outdated versions of snap, and so I can’t make use of symbolic links without breaking icons for users.
Symbolic links aren’t the only case, each new release of snapd gives new features, but currently there’s no way of knowing how many that is, and I feel as if it would be useful to have a metric on the store page alongside installs by OS/Arch/etc, installs by snapd version, so we can accurately know just how many people can make use of certain functionality that might not be consistent from one snapd release to another.
Does this sound reasonable? I’m hoping that snapd clients actually advertise their snapd version the store to begin with, but if they do, I feel this would be useful information to know for packagers.
If you’re using a feature which you know is only available in a specific version of snapd, you can use assumes to prevent your snap from installing (and breaking) on unsupported systems:
(of course if the target snapd is old enough that it itself doesn’t understand assumes then you’d be in a bind - I don’t know when assumes was introduced).
Using assumes is a possible solution but it essentially means just not pushing updates to users entirely, I’ve used assumes in the past and the users really don’t seem to appreciate it, for the icon situation above, I would much rather just stick to absolute links and keep updates to older snapd clients than forever doom them to no more security updates for theming support they might never use.
For example, when the pulseaudio --> audio-playback interface transition happened, I used assumes: to ensure everyone had that interface, a Debian user ended up installing snapd from Sid onto Stable rather than using the re-exec functionality, users aren’t always amazing at following instructions, but they’re particularly amazing at finding bad solutions.
If I could determine that I’d only be blocking off say 1% of people from updates with assumes, I might be more tempted. As is, I’m unlikely to ever use it unless it was over a feature that was make-or-break, and not over something as trivial as icon themes. Having actual stats would make it a lot easier to determine the value there.
While the snapd version is sent to the store for refresh requests we don’t currently aggregate metrics around that axis. We could consider doing so - please file this as a feature request at https://launchpad.net/snapstore-server and we can evaluate from there. This won’t help you in the very short-term however.
Fortunately for myself not having an immediate solution isn’t too problematic for me personally, and in the long-term late is better than never, fragmentation as a problem likely won’t ever disappear so it’ll still be relevant in the future for other people who might wish it existed too.
