Currently offline updates are a wholesale affair. Either all updates are offline, or none. Given the current situation that packagekit manages appliciations as well as the system core packages and offline updates are mostly only called for with core packages a whitelist feature would be good. Packages matching the whitelist would trigger an offline upgrade if they are in the list of packages of an update. Otherwise discover performs a regular online upgrade. This whitelist would be provided by the distro. The format still needs figuring out, this probably needs at least simple wildcard support. We could probably just have it be packagname strings and run them through fnmatch? May be slow to iterate all the packages though.
How would you have this work? Could you tell me what kind of whitelist you have in mind for e.g. Neon? Also feedback on how this should work for Fedora/Suse would be useful.
From a Fedora and Mageia perspective, I would expect that the filter for mandating offline updates would be when you're requesting updates of content that doesn't have AppStream data. GNOME Software filters this way automatically, and things not associated with an app update will be set aside in the "OS updates" category and that triggers a reboot. I imagine the same mechanism would make sense here, and unifies the handling across packages, flatpaks, and snaps.
Also, to the idea of a package whitelist, that's absolutely bonkers. I don't know how that would reasonably scale. And how do you deal with virtual packages, renames, splits, etc? It's too cumbersome. It's better to use a property to identify what qualifies as non-OS content to not trigger an offline update.
@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
@Harald If this is a transient thing, what would the end-goal be? All packagekit packages are offline?
(In reply to Aleix Pol from comment #5) > All packagekit packages are offline? Really long term yes. Yes. Perhaps somewhat less long term: anything that is not associated with an application component in appstream. Ultimately this could be a distro side decision actually, depending on the specific distribution either may be suitable.