On updates

[Joaquim Rocha <jrocha endlessm com>]

Howdy,

I am working on bringing auto-updates to GNOME Software. This is the same functionality that phones usually have, where when connected to WiFi, apps are updated automatically.

There's currently some tentative design for this feature in [1].

tl;dr I would like to know how updates are being used by other vendors, and to eventually simplify how they're performed in g-s. There are a few questions down below, but you should maybe read the whole email for context :)

We have already a somehow similar feature in GNOME Software called "download-updates". This setting tells plugins they should download updates during refresh, so the new versions can be later installed/deployed. Although I understand that for packages this is good because installing a version of a package-based app while the app is running can lead to problems, it is not good to base the whole design in this principle, especially taking into account we now have things like Flatpak that can be safely fully updated even if the apps in question are running.

I think that (at least) Flatpak should not have this distinction between download+update in GNOME Software (not shown to the user at least) since it's not at all how users think of updates, and that's also probably why phones don't do it like that either...

I exclude offline updates (OS upgrades) from here because those obviously need to be done in that way.

I have previously requested from Richard that we should be able to still show updates in GNOME Software that aren't downloaded (list of apps that have new versions) and this motivated having two plugin methods for adding updates: gs_plugin_add_updates, gs_plugin_add_updates_pending.

However, the latter (updates that aren't downloaded) is not called unless download-updates is false, and that's not great because with auto-updates, that setting should be on, but I'd still like to show the list of apps with updates to the user (even if they're not downloaded). Besides, having two methods to fetching updates seems overkill.

Downloading updates is being done inside the refresh method, and this method is also used to refresh the metadata, loading new sources of apps (e.g. in Flatpak a new remote may have been added). I am not sure, however, that the refresh method is the right place to download updates. So far, downloading updates automatically (through refresh) has been triggered by the updates-monitor, and happens completely separated from the UI, but I think that if the UI is being shown, then users should be able to see that the apps are being updated, and be able to cancel the op if they want.

Using the GsApp objects inside the refresh method when downloading the updates is still possible, but a better integration with the plugins would be to have a plugin method to override called: gs_plugin_auto_update or gs_plugin_update_all. This way, not only plugins could keep the refresh only for metadata stuff, but also we could have a better integration in the UI (by emitting a signal "update-all" from the plugin-loader, we could better control the UI actions in the updates-page, like setting the right state to the "Update All' button). This may require some new app's states like PENDING_UPDATE (so we show all apps as pending updates in the UI), but overall I think updates should be simplified if we go with these proposals.

1) Are you okay that we call add_updates_pending even if download-updates is on? And if both methods are now very similar, should we just have one add_updates method (breaking API or deprecating add_updates_pending) like I intended originally (and it's up to the plugins to decide how to handle the updates).

2) Should we have an update_all plugin method as explained above?

3) Should download+later_deploy be a use-case only for packages in GNOME Software, or do you think it's the way it should be for things like Flatpak/Snap?

[1] https://wiki.gnome.org/Design/Apps/Software/Updates#Tentative_Design

Sorry for such a long email, and thank you!

Joaquim Rocha  |  Endless