https://bugs.kde.org/show_bug.cgi?id=399371
--- Comment #4 from Harald Sitter <sit...@kde.org> --- @Neal this is a transient thing. the long term goal is to have offline updates enabled for "some" parts of the system (the some part being real long term anything that is not a bundle IMO). However, before we go there we need a way to actually test this in production. That's where the whitelist comes in. We can have very limited coverage so users do not get offline updates all that often, but just often enough to give us feedback on the user experience. @Aleix example list for neon ``` - nvidia-* - linux-image-* - libkf5kio5 ``` If any of these is in the set of packages for update the entire update would be switched to offline behavior. Discover could instead call a helper binary and give it the list of packageids and that returns 0 or 1 based on whether the update should be offline? Which not that I am thinking about it may be the nicer solution from a discover POV. UX-wise I expect this should be much like the final goal for offline updates: - User starts updater - clicks upate all - update runs; includes nvidia-* so it runs offline - discover informs the user that they need to restart to complete the update - updater plasmoid changes icon and is now in "restart" mode where it asks the user to restart to apply the update and has a button in the popup to start the restart - user reboots; updates apply; restarts to updated system -- You are receiving this mail because: You are watching all bug changes.
