On Wed, Nov 10, 2021 at 11:50 AM Kamil Paral <kparal(a)redhat.com> wrote:
On Tue, Nov 9, 2021 at 3:47 PM Ben Cotton <bcotton(a)redhat.com> wrote:
>
> So I still disagree with you, but my position is softening. I'd rather
> we have a clearly-defined and understood set of criteria that I
> disagree with in some places than to try to make every criterion match
> my preferences. :-) So while I disagree, I'm happy to move forward
> with this.
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.
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).
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).
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.
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.
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.
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.
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.
My take, all except 6 are blocking.
--
Chris Murphy