Snaps seem to be a great idea and I’ve already seen various improvements in the short time I’ve been using them. I don’t particular notice the speed problems people talk about.
Yet, this issue just seems like one where the business requirements of SNAP’s users don’t match what it is being designed for. It ‘looks’ to me like that snappy design team is viewing the SNAP store like the Google Play Store or something. Primarily something to be used by average users on their home devices (like smart phones). So… why not force them to keep it up to date?
Yet, the SNAP store is being viewed by its user base as a general linux application deployment system. The original post is really a great example of why the auto-update system breaks these use cases. If it’s doing any kind of services/networking, you can’t just have it auto update. Not to mention most organizations have rules and processes in place that they expect the software to be subservient to. Not the other way around. You don’t buy/install software and then rewrite your business processes. You buy/install software that meets your business processes.
I’d really suggest if this hard line is going to stand, just come out and say that the SNAP store is unsuitable for general enterprise use. Developers, such as the OP can then host local SNAP files on an FTP server or something. Their user base can then update it manually to their hearts content. Or maybe you push people on those cases to use private SNAP stores, where those kinds of options can be configured.
Alternatively, I really like one of the suggestions I read where there is a file where you can configure SNAPs which should not be auto-updated. You can even make editing this file require root. You can even mandate it is the exact file name, and not some regex. This would really emphasize that you need to add apps manually and not just * I really like this idea because
- It keeps apps up to date by default
- It makes non-auto-update apps an exception. For example, in the OPs case, his customers might only want to have his SNAP not auto-update. But other SNAPs which might not cause downtime can auto-update.
- The non-auto-update apps are all tracked in one place. This is great from an audit point of view; especially in the enterprise. To put it bluntly, whoever made that change to exempt that SNAP will be responsible if a non-updated app causes problems.
This could also be used in conjunction with a flag on the SNAP itself which indicates if the developer of the SNAP allows the SNAP not to auto-update. Feel free to have whatever process in place to approve that flag. That at least shifts the point of contention to developer-SNAPSTORE. For example, if there was ever a valid use case, the OP (networking products) should definitely get approved for such an flag. I just throw this in as no doubt you want to avoid everyone throwing that flag in there by default. You want to keep such things the exception.