well your question was:
you did not ask about beauty 
This behaviour is disappointing.
I will not accept half-baked or hacky solutions, I am here for a potential recognition from canonical about how much faith they’re losing with this stunt, if they might recognise/see it or not.
Sassiness in the face of that is definitely not appreciated @ogra, it’s not funny nor agreeable, and if you have a problem with my conduct, state is explicitly, or else be constructive about the argument.
This thread has gone on for a year, I’ve seen person after person complain about this, yet I’ve seen developers and other people then gaslight and subdue them into “it’s okay, really”.
I do not tolerate that anymore. Forum moderators, please close this thread just if this is not what you want, or state a clear position from canonical about it, and then prohibit any further discussion for it, to finalise your position transparently, because the subject is clearly generating a lot of friction. I see the keeping-open of this thread as deliberate black-holing of this subject, I see absolutely zero good-faith from the developers and moderators with keeping this subject alive, with no clear answer to the question “why can’t you just acknowledge my preference?”. In my opinion this circus has gone on far enough.
2 Likes
I am tired of this thread too… The best work-around is to run Debian. Ubuntu is based on Debian, so Debian will feel comfortable. Debian is super stable and solid. New releases happen about every two years, so similar to Ubuntu LTS. Debian is a community distribution, so you can have a say and contribute. Maybe this is why community distributions (Debian, Arch, Gentoo, etc) or so popular and such a good choice. Best of all, Snaps are not required (or used unless you install snapd yourself).
2 Likes
How do we create a brand store? I’m not sure if that’s the same as my snap store i have now.
i’ve had FORCED snap updates break my server installation FAR more often than i’ve EVER been at any ‘security risk’. You take away the ability to NOT FIX what ISN’T BROKEN. A STABLE UNCHANGING system is FAR more important than a BROKEN one ANY DAY.
I’m avoiding snaps at ALL cost from now on, and my colleagues are seeing the carnage and shying away.
Without a way to indefinitely HOLD a package, some snaps are completely useless.
but what if the snap is already installed and up and running
1 Like
Well, maybe removing and reinstall as I said? Didn’t test, but should work.
it will just behave like a refresh (just that the --dangerous flag will tell it it is a local unsigned package install … (also note --classic is a no-op if the snap was not packaged as classic snap in the first place))
2 Likes
so, i think i found a solution for ME.
sudo snap refresh nextcloud --channel 21/stable
now, when i list all snaps, they all say ‘latest’, except nextcloud which says 21/stable
This will hold nextcloud on 21/stable?
You’ll still receive any new revisions published to the “21” track (security/patch releases/etc), but these should all be from the same major branch of version 21. You’d never update to any newer major versions, even if version 21 becomes end of life, without changing the channel manually.
2 Likes
PERFECT! I think this is what a lot of people are looking for.
Now my personal nextcloud instances will stop breaking on me every time i turn around.
It is a kind of workaround but not a real solution in my opinion. There is still this annoying and unnecessary lack of control (just the channel switched).
1 Like
Disagree, the thread is here so people can just +1 existing comments they agree with (by liking them) to express support for those comments or making new suggestions and providing more evidence that the status quo isn’t working per the below:
I would like this thread to say open whilst this is still an issue and whilst @niemeyer is still asking for real and specific use cases (if he is still asking?) where automatic snap refresh is the problem and where there can definitely be no workaround other than an off switch (there’s quite a lot of snap commandline control now for scheduling updates if you only want one update per month, for example).
1 Like
There’s two answers Canonical would give for this use case I think:
- Outdated software puts both you and your users at risk, yet servers still run outdated software, hence taking the control out of your hands and protecting your users by forcing you to update the software occasionally, unless you hack around that design.
- You can control when these updates are made from the
snapcommandline. Usingrefresh.timer, you can set it to just update once per month at a particular time, so that you can plan around the update. Once an update has been made you can also userefresh.holdto delay updates for the next 90 days.
Please could you specify a real use case where the a once a month refresh.timer and a 90 refresh.hold is not enough? If you can specify a real use case where this isn’t enough, I’m sure Canonical would be very happy to listen, that’s why this thread is still open.
I agree with others that if the workarounds and controls available don’t satisfy you then you need to find an alternative to snappy.
Do read Re-visiting update control on the desktop if you haven’t already, I just read it now, it’s by a very well-respected Ubuntu community member and former (recent!) Canonical employee and summarizes the situation well.
1 Like
I already have.
I’m not interested in regurgitating the same answer once again, read the thread, read my comments.
I would be ok with only the STABLE channel auto refreshed and updated… but all the other channels needed to be manually refreshed. Something at least so we have more control over the auto refreshes.
Correct me if i’m wrong, but if you open a Enterprise app store ($$) with Canonical, you get more control and options on updates and version control? What do small startups like myself do so we can control app updates and not crash customers business computers in the middle of the day all over the world when the 4h auto happens? Our software snap for example, will run games with live customers in-person, and imaging the app crashing to do an auto update bringing the business to a stand still. Having an option to set the ‘allow refresh time of day’ or something would be so nice.
This is exactly what refresh.timer option is for:
So how do we do that on Ubuntu CORE devices we give to our customers? For us, we want to stop any updates on the CORE side, and control all the updates in our web application logic so our customers and pick times to update, or schedule them.
For such setups the usual way is to use snapd-control interface. However, this is a super privileged interface, as such you will likely not be allowed to publish anything to the global store that anyone can use, and are expected to use the brand store (basically the interface allows you to execute all API of snapd, so pushing a bad snap to the global store would mean any user of that snap could be affected, while with a brand store its effects are limited to your snaps and devices). But there are also other options: https://ubuntu.com/core/docs/refresh-control which I think @ogra referenced already. TBH if you’re deploying devices based on Ubuntu Core, I would still think it makes sense to get in touch with someone from the field/sales team. For some reason people seem to focus on snapd and snaps, but for device deployments it’s just part of the problem.
I think it would be useful to have some docs about the typical deployments of devices with snaps, how those are organized, how the device is set up and so on. I had a quick look at core docs, there are docs describing individual building blocks, but it isn’t entirely clear how one would maange a device. Something like a FAQ or use cases. Maybe a topic to research for @degville ?
I think you’re right - it would be really useful if the Ubuntu Core docs had some example deployments, including how they were built and how they’re updated and maintained. I’ll give it some thought and try to get some examples together.
1 Like