Re: On updates

[Joaquim Rocha <jrocha endlessm com>]

Hey Richard,

On Mon, Jan 22, 2018 at 10:14 PM, Richard Hughes <hughsient gmail com> wrote:

On 16 January 2018 at 11:14, Joaquim Rocha <jrocha endlessm com> wrote:
> The information I have is that most of Endless' users have some sort of
> connectivity, but it is unstable and metered or very limited. So they're
> very conscious about it's used.

So in this case you'd just default to "automatic downloads and updates" being turned off?

No. We are currently working on a scheduler that will be able to tell GNOME Software and other apps when its okay to download. But GNOME Software will still have to automatically ask that. So we'll keep the auto-downloads feature on.

refresh() -> download new metadata
get_updates() -> gets the updates that are not downloaded or deployed
update(app) -> download and deploy the previously downloaded app

This is what I wanted with decoupling the refresh from downloading updates, because, as previously discussed, this has two major problems:

1) The UX is terrible: during refresh the updates page is emptied until updates are downloaded, and this can take a long time;

2) We're not able to e.g. queue automatic updates if there is a number of ops already happening at the time.

So I think your proposal looks good.

 

Assuming the auto-updates setting is TRUE, in the update monitor rather than calling refresh(PAYLOAD) we'd be calling get_updates(), and feeding that into update(app). The only slight fly in the ointment is that the update vfunc needs to know if the update() is being called interactively (i.e. with a button press) or noninteractively (i.e. from the update_monitor. I don't know if a different vfunc is a good idea here.

Having something telling us that a function was called noninteractively is very useful as we can e.g. sort those actions to be at the end of the queue, so as to not make the user wait. 

I'd also prefer that we don't use yet another vfunc for it.

We'd still get update progress if we stumbled on the GsApp in the installed, details or update panel, and we'd still be able to cancel the download/deploy action using the GsApp-specific cancellable.

Yup. And this is very important.

 

This allows us to delete get_updates_pending, GsPluginRefreshFlags and a whole ton of code in gs-flatpak.c. It also means we can close a few dozen bugs of the kind "gnome-software doesn't show any updates when pkcon does" where the updates are waiting to be downloaded.

I wonder if the refresh flags are still useful. I prefer to keep them around then deleting them right away and then having to do more vfuncs for compensating the lack of it.

 

For non-live-deployable updates (like PackageKit OS updates) we'd simply download the apps during update() and set them to be deployed on next boot.

Yup, it's easy to filter those out when auto-updating because we'd not do it for apps that have AS_APP_STATE_UPDATE  set to them, only ..._STATE_UPDATE_LIVE.

If nobody dislikes this plan, let's iterate on IRC so we get this done soon.

Cheers,

Joaquim Rocha  |  Endless