On Wed, Nov 10, 2021 at 5:49 PM Kamil Paral <kparal@redhat.com> wrote:

Hmm, let's try something different first. I'll provide a list of scenarios below, and I'd like everyone participating in this discussion to respond whether they think that scenario should be blocking or non-blocking (for Final), and ideally why. Perhaps we can distill some reasonable requirements if we don't talk about it abstractly or with dnf-like comparisons, but with actual examples.

My take:

Scenario 1:
User clicks Install on pkg A. She waits until that is done. Pkg A gets installed correctly. Then she clicks Install on pkg B. That returns an error. After closing and re-opening the package manager, pkg B can be installed. (In other words, only one operation can be performed, and then the manager needs to get restarted).

Blocking. The package manager doesn't fulfill its basic role - install packages (notice the plural). Restarting the manager is a decent workaround - for Beta testers.

Scenario 2:
User clicks Install on pkg A. She waits until that is done. Pkg A gets installed correctly. Then she clicks Remove on pkg A. That returns an error. After closing and re-opening the package manager, pkg A can be removed. (This problem only affects two subsequent operations on the same package. Performing multiple operations on distinct packages works fine).

Blocking. A bug that occurs with multiple operations on the same package is a special case of the above. If I can't install and uninstall the same package over and over again, the package manager again doesn't fulfill its basic role. Restarting the manager is a decent workaround - for Beta testers.

Scenario 3:
User clicks Install on pkg A. Before that is finished, she navigates the interface elsewhere. E.g. seeing the home screen, searching for something, showing the installed apps, showing the updates, etc. Because of this interaction, pkg A installation process is incorrectly aborted (cancelled), i.e. it doesn't get installed. It's a bug, not a design decision. The system is in a consistent state, internal databases are valid.

Blocking. The user performed completely valid actions, offered by the GUI. The user is not expected (even though many do) to stare at a static screen. Quite the contrary, GUIs are expected to be interactive basically all the time (even if they just show a spinner or similar). Aborting the installation fails basic expectations.

Scenario 4:
User clicks Install on pkg A. Before that is finished, she clicks Install on pkg B. Because of this interaction, pkg A installation process is incorrectly aborted (cancelled), i.e. it doesn't get installed, and pkg B installation is started (and finished correctly). It's a bug, not a design decision. The system is in a consistent state, internal databases are valid.

Blocking. It's the same case as above, just slightly modified. Aborting the installation fails basic expectations. The GUI supports queuing actions, it is very visible and obvious how to do it, and so this is a failure within basic interactions with the package manager.

Scenario 5:
User clicks Install on pkg A. Before that is finished, she clicks Install on pkg B. A cryptic error shows up (the user doesn't understand it), e.g. "installation constraint failed: failed to acquire a lock: pkg B". It's a bug, not a design decision. Repeating that action only shows the error again. Pkg A is eventually installed OK, but pkg B installation wasn't even started. Once pkg A is installed, pkg B installation can be started and finished OK.

Blocking. Everything said above applies here as well. The consequences are a bit different (a displayed error vs an aborted action), but both fail to perform the intended task, which was within basic interactions with the package manager.

Scenario 6:
User clicks Install on pkg A. Before that is finished, she clicks Install on pkg B. An understandable dialog pops up: "Please wait until pkg A installation is finished". Once pkg A is installed, pkg B installation can be started.

Not blocking. This is a somewhat fake scenario :-) There is no bug, it behaves according to program design. So it's fully covered by the footnote I wrote. I included it to demonstrate a difference between seemingly similar cases, but one is a bug and one is a correct behavior. (Of course, even better would be to disable Install buttons while some operation is in progress, and avoid those dialogs, but that's not the point here).

Scenario 7:
User clicks Install on pkg A. Before that is finished, she performs a different valid action. That can be navigating to a different screen, or clicking Install on pkg B (the particular action is not important in this scenario). That second action triggers a bug and pkg A installation is incorrectly aborted in a non-clean manner. The system ends up in an *inconsistent* state, i.e. internal databases (like the rpmdb or dnfdb) are damaged. No further package operations (installations/removals/updates) are possible, everything results in a cryptic error. Rebooting the system doesn't help.

Blocking. The system must not get damaged, if only standard operations are performed (and at least with gnome-software, it's designed to only contain basic interactions, i.e. it's hard to stray into some niche power-user corner case approach; that might be a bit different with plasma-discover, or of course dnf).