Does the snap auto update handle subscription software?

With (done correct) software subscriptions i mean the business rule that you purchase some software and than have all updates for a certain amount of time (usually a year).

So for every update the snapd updater need to send some personalized data to an authority third party server to accept if the auto update can be done or remind the user to extend the subscription unless the snap store itself is offering payment functionality which we are told is currently still not on the agenda.

I dont want to always update and one morning let the user come into office to find out that the subscription is over and they can’t run the software anymore and need to find out how to restore an older version and to disable auto updates. Is it even possible at the moment to disable auto updates on individual snaps?

I’m not sure I follow. Snapd only talks with the snap store. When a new revision of the snap is published in the snap store, it will eventually end up on your host.

The subscription model you describe is usually implemented in an application and very simple to enforce if that application is primarily a fronend to some remote service (eg. spotify?). Snapd is not involved in this.

a snap could indeed do a check in a post-refresh hook to check its subscriptions after a refresh … if the check fails it will roll back … but this is all completely a job of the package maintainer…

This sounds almost good but is not. Because that poor user will always download the snaps for no reason. Worse, the system will find the snap again at the next update interval. There are a few updates per day as default (i read something about every 8 hours/4 per day) . That would result into an absolute unacceptable and not just a bad solution.

It’s easy if snaps could get some kind of update API to specify things like this to snapd.

By the way for debian packages i’m planning to setup an apt reposository where each customer gets it’s own repository URI. And there is still sparkle for non packaged.

@ mborzecki, no you did not follow correctly. The program should not become unuseable when the service ends but the user should be allowed to still use the last version published in his subscription time in perpetuity. Its the only software subscription model many people like.

I would really like to see Linux and snap or flatpak be successful, but the developers really must listen more to the community and especially to the developers. And especially to the developers of proprietary software. It’s the reason why Linux on Desktop is failing again and again for 20 years.

erm … so you would upload a new snap multiple times per day ?

a post-refresh hook only runs after there has been an actual upgrade of the software package, not on every check for updates that snapd does…

see the definition of pre- and post-refresh hooks at:

I don’t understand the pre-refresh hook documentation “because if the test causes the hook to fail, the refresh will not proceed”.

Because it does not define what will happen in the fail case. So i assume the downloaded snap package will stay in some cache directory and not downloaded again. So it would download each new package in perpetuity but only once per changed version upload. Is this how it works? This would indeed be at least useable.

What are the sandbox rights of the pre-refresh hook script?

8x4=32, I’d get a lot done with a 32-hour day :slight_smile:

  • Daniel

i doubt it will be cached, typically a failing snap is marked “bad” and will not be retried again, only the next revision coming from the store will be able to unset that state, so it would make no sense to keep the failed one around.

the sandbox rights are the ones you defined for the hook in snapcraft.yaml. like for apps you can define interface plugs to talk to the outside world … beyond this, the hook can do anything it wants inside the confined environment.