| Summary: | offline update whitelist | ||
|---|---|---|---|
| Product: | [Applications] Discover | Reporter: | Harald Sitter <sitter> |
| Component: | Updates (offline) | Assignee: | Aleix Pol <aleixpol> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | wishlist | CC: | aleixpol, alex765, fabian, geisserml, krammer, lnxusr, mark, nate, ngompa13, onlineplayer.dp, rdieter |
| Priority: | HI | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Flatpak | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Harald Sitter
2018-10-04 10:36:28 UTC
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. I suspect this isn't going to be implemented; it's been 7 years since this last had any movement, and many other changes in our ecosystem have happened since then that make it less useful or likely, including the rise of immutable/image-based distros, and the decline of PackageKit itself. *** Bug 435574 has been marked as a duplicate of this bug. *** *** Bug 435623 has been marked as a duplicate of this bug. *** *** Bug 435703 has been marked as a duplicate of this bug. *** *** Bug 438393 has been marked as a duplicate of this bug. *** *** Bug 440126 has been marked as a duplicate of this bug. *** |