This is because when I’m at work, I don’t want software updates to interrupt when I’m doing my work. I have had quite a lot of issues with apps because they updated in the background without me noticing and gave errors, some examples:
Slack not working properly, needs a restart. Very annoying while in a huddle (video meet).
Firefox requires restart. Very annoying with many tabs open, especially when sessions/logins are not preserved. Also some webapps just break down, which is even more annoying when you just want to do your work.
Evolution mail client sending empty mails (had that on 2 systems, and another coworker had it too). Baffled me because this is core functionality and led me on a hunt through the mail flow, only to find it was an Evolution update.
With the rise of snaps, this behavior has become more intrusive, updating as soon as an update comes available, not offering any GUI options to influence this behavior.
So I always manually install updates before I reboot or shutdown, this only takes a few minutes and guarantees less of these issues.
For the more technical users, this can be easily fixed by themselves as a script or implementing user fixes (like sudo snap refresh --hold=forever). I have been doing that for the last 12 years or so, so this feature is not for me. This feature is for the users who try KDE for the first time. For users who don’t see a cli very often these update symptoms can be very interruptive and even discredit/undermine the trust in the system, especially for new users. Granted, I would think new users would not immediately go for KDE based systems, but I still think it is a valuable addition for Linux acceptance. My family systems and new users (yes, users, not techs) within our company are using Kubuntu and they fall into this category. I can even imagine this would be a good addition to Ubuntu, but as I love KDE I would like to start the discussion here. I might request the change at Ubuntu too, but let’s wait what you think of this proposal first.
I was thinking of the following feature request:
add an option to “automatically” to install at reboot/shutdown. I would add a comment that this will cause the reboot/shutdown to be slower.
add an option to “automatically” to offer to install updates when choosing restart/shutdown. This would require some tinkering with the restart/shutdown to provide a popup after shutting down. Or perhaps a better option would be to offer a box at the logout screen.
For both options:
I would only add this option to the restart/shutdown button of the launcher, leaving the default behaviour of other shutdown/restart processes/apps unchanged. So only the more novice / GUI oriented people can benefit from it.
I would offer this option to security updates as well. I have it set to after rebooting only because I manually update security updates after every shutdown/reboot anyway. But I would prefer this to be at shutdown instead of after a reboot.
If this is a feature worth investigating, it might be worth changing the UI defaults (most techs can find the options easily in the GUI). Or some way to determine if they understand software updates or not and let the system decide the best defaults for the user. But that would require more interaction with the user at first login, so that would require more thinking what is the best action for all users. I would suggest making the default the most sane for all users, like the single click in Dolpin.
Maybe a stupid question (because I have never used Kubuntu), but what application is that window you show? The “software update” window?
The reason I ask is because I don’t think KDE handles system updates (other than arguably on Neon), and even though your post is very well written, it might be the incorrect forum.
I have updated the screenshot to include the system settings view. From there I filtered on updates.
As far as I know this setting can influence how the OS updates it packages. On Kubuntu 23.10 the screen is somewhat different, but still there:
My system is indeed KDE Neon stable, so I would argue if this is a good idea, to implement it there first and decide later how it affects other distro’s.
I think KDE just offers a GUI way to change the package manager options that are already there. I would suggest that these screens read the package manager config file and only edits basic functionality of the functionality that is already there. I see nothing wrong with that.
But if you do you probably have a different view and please start a different thread on that as I’m afraid of sidetracking my intended discussion. I’m happy to discuss meddling desktop managers with package managers…
Snap doesn’t obey those settings, and neither does flatpak for that matter. But snaps will only update when applications are not running (it will put an annoying notification reminding you to quit the app, but then won’t update when you quit the app) and AFAIK flatpaks do not auto update at all.
Regardless, if you’ve set the update behaviour to “manual” you shouldn’t worry about the system applying updates while you do other things.
That being said - I do agree that an MS-Windows; like behaviour of “update before shutting down” is a nice feature to have. Maybe there’s no need to change the software update KCM - just do it like Windows does - if Discover thinks there are software updates, offer another action on the shutdown screen to “update and shutdown”.
This will not work for Arch based distros, because unlike Debian based distros where package manager gives you an interactive prompt that lets you choose what to do with config files that were changed by user in /etc/ and if you want to overwrite them with new ones.
On Arch based distros, pacman doesn’t overwrite those modified config files and creates a bench of .pacnew files that should be processed using pacdiff after finishing all upgrades, and sometimes if you forget a .pacnew file related to a dangerous package like systemd, grub… then your installation or session might fail to boot the next time.
These files require manual intervention from the user and it is good practice to handle them right after every package upgrade or removal. If left unhandled, improper configurations can result in improper function of the software or the software being unable to run altogether.
So, if I understand correctly, on Arch there can be no automated updates - at all. The Software Updates KCM might as well be disabled and removed. I would expect Arch packagers to take care of that and obviously the shutdown screen should not show the the option to automatically update the system during shutdown - if automatic updates are not possible.
KDE’s Discover uses PackageKit to update, install and remove native packages on pretty much any distro other than arch and has done so for quite a while. You’ll find this settings page on pretty much any default installation of Plasma.
I did not know that.
Still sounds risky af but honestly great, if it works…
A questions about this.
When you get asked what to do with new config files, because yes, debian does that too, not just arch with pacnews.
On my raspberries and debian servers I just use the same method as on arch, use vimdiff or smthn, because the merger in apt, yeah no.
But how does most debian users do that?
And how would discover handle that?
Edit
I just found the answer to my own question on the faq:
How will PackageKit handle installation an application that needs user interaction?
Upgrading, installing or removing packages has to be 100% silent.
The user cannot be prompted mid-transaction for questions as these will not be handled in PackageKit. The backend should do the right thing, as these questions mean very little to the average user.
“Means very little to the user”… Ok?
The last time I had to merge a file on a Debian server not too long ago, I think it was changes to my sudoers file, not sure I would say that “means very little”, but ok…
So the answer is: it doesn’t.
I guess, “ignore until next release” is the mantra. xD
Generaly it could be usefull to do in a Windows kind of manner: update & shutdown/restart button at launcher.
For some distros this is not an option, like Arch. I would suggest to exclude them as I target non-tech users and don’t expect many non-tech users will be using Arch.
