GlowInTheDark wrote: ↑
Wed Dec 11, 2019 1:06 pm
2) The more generic issue of: is there anything that can be done about the upgrade process stopping and needing user input. This has two implications:
a) It means you can't do a fully automated ("no touch") upgrade. You can't walk away and come back in half an hour or so and expect it to be done. You can't (as some people on this forum have suggested over the years) put it on a cron job.
b) The unsophisticated user won't know what to do. We can't just tell them "Do the upgrade and everything will be fine". There's no real answer to this; about the only advice that can be given is "If in doubt, take the default".
I realize that there is no simple answer to this. If there were, presumably, apt-get would know what to do and would do it. The fact that they have to prompt, means there really is a problem.
BTW, what I just wrote is not 100% true. Sometimes, the upgrade process stops to display some kind of message (often about security/SSL stuff) that either doesn't require *any* user input or if it does, it is pretty clear what the correct action to take is. I.e., it could just go ahead and do it and not bother the user with a bunch of unnecessary "stuff" as well as unnecessarily pausing the process.
But, as they say, it is what it is...
Not sure if I agree with you. If you have a generic/default system it will work just fine. If you have made changes to system config files what do you think it should do? It could automatically overwrite your changes (will toss whatever customizations you made, and maybe break the system, certainly will change the way you expect it to behave), keep your changes and not get whatever is new (new functionality may not work or you may end up with a broken system), or try and merge the two files (a fairly sure recipe for disaster). Personally I run updates interactively and actually read the info. In most cases the best approach it going to be take the new, and then add back in your changes after you validate that they are still relevant/correct. You do keep copies of changed system config files right?
The unsophisticated user should not be mucking about in system config files, unless they are willing to accept the consequences. Just because you can, does not mean you should. This is one of my biggest pet peeves. Assuming a similar level of knowledge, most folks would never consider tinkering with a car engine or changing their electrical panel, but happily will follow a web page or youtube video blindly, without a clue of what the commands are actually doing. These same people then get upset when their system breaks horribly, and when asked tend to say "I did nothing". I have no issues with people tinkering and learning if that is their intent. The Pi is great for that... make a copy of your SD card and tinker away. If it breaks, swap the card and voila you are back to an unbroken system. But you at least need to understand the ramifications of what you are doing. If you change stuff, it may break. If you go down the rabbit hole of trying to apply a incorrect set of instructions written for a different version of the distro, or even for a different distro you may break it horribly enough that your only sane recourse is starting from scratch with a reinstall.
This is also why it is a good idea, whenever possible, to tweak configuration files at the user level rather than the system. A system update will never overwrite user level changes and it is fairly easy to resolve unexpected behaviour by testing with a generic test account.
You certainly can do unattended updates. If you want finer grained control use apt-get and the "quiet" and "yes" options. However, understand that doing so comes with certain risks as it will make decisions for you. If you are worried about stuff you could always do a simulation and check what it is going to do and then run it.