On Wed, Nov 10, 2021 at 11:50 AM Kamil Paral <kpa...@redhat.com> wrote: > > On Tue, Nov 9, 2021 at 3:47 PM Ben Cotton <bcot...@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 _______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
