I’ve written up my experience of using the Snap version of Gitea, which is currently quite broken. I’m not trying to troll here, but I think there are significant problems with using Snaps for services despite the conveniences.
https://gld.mcphail.uk/posts/how-i-broke-gitea-for-everyone/
The edge channel is actually promoted to developers to use it for automated builds from HEAD (so they can see issues with their commits immediately), do you think we should have better documentation here or some such to prevent others to fall into the same trap eventually (note that packages that only have releases in edge are not even found by the various GUI tools to not have people install untested software by accident) ?
The packager here was doing the expected thing and using edge for its intended purpose. I, the user, was at fault for switching channels. If there was any fault on the packager’s part, it was in the labelling of the version in the edge channel which was based on the last git tag despite the package being built from HEAD.
It has been a good number of years since I fumbled with snapcraft but at that time it was still a bit awkward to set the version of a build correctly. Would it be set to a git hash? Would the package, then, have to be rebuilt if it was to represent a release version being promoted from edge to stable? (This may all have been improved in snapcraft and the store since I last looked at it.)
The bigger issue here is that if upstream breaks stable it breaks for everybody immediately. It takes a fairly knowledgeable and diligent packager to avoid such situations, and I’m not sure there’s a critical mass of knowledgeable and diligent packagers out there for a system like snap. I know Kyle had sweated blood to keep Nextcloud functioning well, but that’s a singular individual for a singular package. I can’t imagine many upstream teams have the benefit of such rigour and devotion.
Right, it is clear that this was your fault, but I was wondering if we could do something to prevent users from switching to edge on production systems (perhaps having an extra y/n question or whatnot that would have made you think twice)
While there were changes in the build process so that you have more opportunities to auto-fill the version string, the management of channels has not changed, if a maintainer desires to move the binary snap from edge directly to stable they can still do so (though we suggest to iterate through beta and candidate with CI tests, we do indeed not enforce anything here) …
The store allows phasing of updates so a maintainer would be able to get feedback from a small group first before fully releasing to the world … for you as end-user there is always snap revert but that will indeed not help if database formats have changed in incompatible ways, here it is up to the packager to actually store their database in $SNAP_DATA (and not $SNAP_COMMON) to make sure it is tied to the running version, that way rollbacks work even in the “incompatible data” use-case …
Unfortunately the $SNAP_DATA approach isn’t ideal for snaps like gitea or nextcloud where there could be terabytes of data being duplicated on each update. I’m not sure there is a good solution for rollbacks for services that are forced to use $SNAP_COMMON for this reason.
If you had put a banner saying “Switching to the edge channel is only for developers or idiots, do you want to proceed?”, I would’ve typed “Y” because I’m one of the latter. There is no way you’re going to save me from myself. On this occasion, though, events conspired to bring the rest of the world down with me. Those poor people are going to have to learn about snap revert pretty quickly and pray that another faulty version isn’t promoted in the meantime to flush their working archived version from cache.
Maybe not, but whatever the nextcloud folk are doing is the right way, so unfortunately, using nextcloud is a poor example for your argument. I’ve been using the nextcloud snap for 6 years without issue.
As mentioned above, I think nextcloud is an exemplar of a snap delivered correctly, but it has required extraordinary effort to do so by a highly skilled and knowledgable maintainer.
Not to add insult to injury, but the initial switch to edge was probably in the wrong direction. That should have been the moment to snap revert on a production system. There is also a less permanent way of installing only a singular version from another channel without actually switching to it, which I use whenever I am impatient and want to get the latest major release of Firefox, without having to wait for the QA cooldown.
sudo snap refresh --revision=<revid>
And, since the FF snap can’t be updated while it’s running, most of the time at least – there seem to be exceptions – I can just leave it running. Once that revision trickles down into the stable channel, only the snap info part pertaining to the channels changes.
Or I could just hold refreshes for that particular package:
snap refresh --hold firefox --revision=<revid>
That can be required to prevent snapd from downgrading to the stable channel version, which has happened to me, while Firefox was running; I only noticed because I actually did restart it and was warned that opening a user profile touched by a newer version of FF was dangerous. That may have been an instance of said exceptions, because usually snap refresh firefox is blocked by the running instance. Or it was just snapd doing a switcheroo to the already installed older revision, because it matched the tracked channel? Anyhow, I only want to illustrate what can happen when doing such things; take whatever you want from the Firefox example.