| To whit - - | Canonical has moved to this system in their implementations of both | snapd and also lxd. It is possible to reduce the frequency of the upgrades | from a daily inspection and possible update/upgrade to a maximum of | a month long period without update/upgrade.
Are you saying that updates are mandatory, but only for snapd and lxd? That sounds a bit odd.
Is it only security updates that are mandatory?
Snapd is used to install lxd.
Do you need snapd to install lxd? Doesn't apt-get install lxd do it for you?
I don't use snapd and lxd. Abstractly, both need to bridge between an inside environment and an outside one. Are the updates purely to the inside, to the outside, or both? Could the updates be required to make this bridging correct?
Not sure - - - just know that snapd can be set for an update/upgrade once a month. If that doesn't happen - - - well my system (Debian 9) would shut itself down.
This led me to, umm, blink. Debian forcing updates? That is most non debian behaviour I have heard of. Some googling around led me to the conclusion that it is not Debian mandating the updates, but instead snapd. Snap is a "universal package manager" for Linux. One of its key features is, you will always be running "updated" software. I can see where it can be useful (really in container deployments, where you could be running some ancient piece of software, and leaving unpatched security holes). I don't see why it needs to be running on "managed" systems (essentially systems where you are actively administering and applying updates as needed). Do you mind me asking what the rationale was behind installing snapd? Or is it just installed by default (sort of hard to believe that Debian won't be looking to fix that mistake).
I thought that one of the goals of snapd and of container systems was the decouple versioning of inside and outside. What other purpose is there for snapd, for example?
My guess is that this tightly coupled behavior would make it much easier to create a fee for such connection. This then monetizes the software. Both of these 'technologies' development occur after Canonical was rumored to be contemplating an IPO.
I would not go with the conspiracy theory. There is a push towards containers, and standardization of package managers and updates is a problem that needs to be solved.
| I found out the hard way that this was a MUST from the software. Myself | I prefer to update/upgrade periodically - - - usually checking to make sure | that the software isn't going to get borked because the upgrade has flaws | in it (even more fun when the system gets borked due to flaws in the | software!!). It was suggested that it would be possible to skirt around the | constant update/upgrade cycle by using a firewall rule to hinder the forced | reach out from my system to 'mother ship'. Well that joy set up a system | that after such an update/upgrade request was blocked - - - well the system | would shut itself down. It was only after the second such incident that I | started investigating and by the fourth I could call the trend. Now I have | the issue of having directories that I am unable to remove even using rm -r | but there is a very long and definitely not simple technique whereby maybe | I will be able to purge my server of said mess.
Wow.
It would be interesting to know what the rationale for this is. There's a chance that the reason is reasonable.
The rationale - - - stated is to make sure that the user never has outdated software. (Implied is that users are the major issue causing software problems.) Not explained is why there is a need to run software on the bleeding edge. There just is no room left for something like Debian stable or software that is rock solid stable - - - there were a number of interesting bugs that showed up.
There are very good reasons to be running on the latest. Especially in community distros, where there isn't a full time team to analyze and backport fixes to the distro. You might not be an average user, but the average user doesn't understand how different bugs can be exploited, and if it is easy to update the package, then that is the right thing. And if something else that it depends on breaks, that software should be fixed. Most library developers I know are very careful about not breaking software that depends on them. When a breaking change does happen, it is publicised and deprecated with enough time for applications to update themselves. If they don't I don't have too much sympathy for them being broken :-). So, if you are on a community distro, and updating frequently, then this shouldn't matter to you. If you are not the average user, and do understand the risks involved, then either you are updating the library/application yourself, or paying someone to do that for you (aka enterprise distros). Now, what you are talking about is not a Debian issue. It is a snapd issue and I think most of your troubles will go away when you remove snapd
It's open source. You could rebuild it without the mandatory update feature. Or you could file a bug report. Or you could accept this loss of control. Or you could walk.
I don't have the skills to remove the offending part of the software. The forum topic where this was discussed was locked by the admins at least a few times as the users would be less than totally amazed and enthralled by the 'feature' and taking the dev team to task re: this gaff. I chose the last option.
This really seems like a user error to me. I don't see the need to install snapd by default. I am really interested in understanding the rationale behind installing snapd. From what I can make out, snapd should also be limited to the packages, snapd installs and manages. If canonical is recommending using snapd by default in ubuntu, then that should be corrected there. Dhaval