Qubes Update tool behavior is nonintuitive when there are no updates available

[deeplow]

How to file a helpful issue

Qubes OS release

4.2

Brief summary

If one starts the updater via the terminal and there are no updates, the flow has some unnecessary steps.

This is understandably an uncommon situation since most users will only ever open the updater through the updates available in the tray icon.

Steps to reproduce

qubes-updater-gui --update-if-stale 1

Expected behavior

It should either show nothing or a green / reassuring message like this: (I created this on photoshop)

Actual behavior

Step 1	Step 2	Step 3	Step 4

Issues:

• step 1 is scary-looking and should instead be reassuring
• steps 2-4 are unecessary

[DemiMarie]

The updater has false negatives and can think a qube is up-to-date when it is not, so there are legitimate reasons to update a qube that is marked up-to-date. But the updater should not waste time when there are no VMs selected to update.

[piotrbartman]

I can change the red badge to green, no problem. I also fixed the issue with the extra steps. However, changing the message content isn't entirely a good idea. The message indicates that there's nothing to do, not that the system is fully updated and this is correct. For instance, this message will appear when I run qubes-update-gui --templates --skip debian,fedora (assuming I have only two templates). In this case, no qube was selected for update, but it doesn't mean everything is up-to-date (and we still have notification about updates). Maybe we should add some extra flag such as --quick which use default smart targeting (i.e. qubes-update-gui --quick will be equal qubes-vm-update but with gui) and then if still is nothing to do we can show message that system is up-to-date.

[deeplow]

Thanks for fixing this!

For instance, this message will appear when I run qubes-update-gui --templates --skip debian,fedora (assuming I have only two templates). In this case, no qube was selected for update, but it doesn't mean everything is up-to-date (and we still have notification about updates).

Good catch! This is kind of an edge-case situation because few people will invoke it from the terminal. Could it make sense to have a different messaging in situations like that? Something like: Selected updates successful or something similar?

Maybe we should add some extra flag such as --quick which use default smart targeting (i.e. qubes-update-gui --quick will be equal qubes-vm-update but with gui) and then if still is nothing to do we can show message that system is up-to-date.

[piotrbartman]

Ok, so I need a little more clarification what should be done.

My point is:

1. We should never assure a user that something is up-to-date if there is still notification in the tray (it's inconsistent).
2. We should keep behavior of qubes-vm-update and qubes-update-gui consistent. But we have to remember that the default behavior of these apps are different. The first one use a default system settings to run updates. The second ask the user to confirm pre-selecting list of qubes (which base on the default system settings).
3. I'm ok with showing System is up to date if the user updates with the default settings and there is nothing to do (it's always consistent with tray icon). But if user chose custom options it's hard to say if there is nothing to do because (i) all qubes are up-to-date or (ii) nothing was selected to update because of a user mistake. The qubes-update-gui has no possibility to update with default settings without user interaction (you have to click Update button). In this situation Nothing to do is not a case.
4. In short if we show a message System is up to date and then we run just qubes-vm-update nothing should happens. In case the user run qubes-updater-gui --update-if-stale 365 and then run qubes-vm-update probably some of qubes will be updated...

This is why I suggested qubes-update-gui --quick, which skip a user interaction, after which we can confidently show message System is up to date since it's not violate last rule, i.e. the user can run qubes-vm-update and it will do nothing after that.

[deeplow]

I see your point. Consistency with the tray icon does make sense. I should have clarified our goals (FPF) - the use-case we're interested in is having as little interaction from the user as possible, because the Qubes updater is launcher as a step in SecureDrop "updater" (we also do other kinds of updates). So for example, the System is up to date or Nothing to do would ideally not even show up and just exit with zero. The situations where it could make sense to enable user interaction would be if something fails, to let the user understand what failed and acknowledge it (this is already current behavior).

Would it make sense --quick or --interact-on-failure to have this behavior? In this sense it would respect all the --targets rules just avoid any unnecessary messaging. This goes a bit in line with what --targets already does: it starts the update without needing an ack from the user.

I can see this being useful beyond our use-case as well. An advanced user may want to have the GUI updater targeting certain critical qubes and just have it go away after updates.

But with that said, having already already cut the unnecessary steps already achieves 90% of our needs. Being able to skip this messaging would just be the cherry on top, so long as having a flag / default targetted behavior like that makes sense upstream.