On Wed, Nov 3, 2021 at 5:15 PM Frantisek Zatloukal <fzatlouk@xxxxxxxxxx> wrote:
On Wed, Nov 3, 2021 at 12:32 PM Kamil Paral <kparal@xxxxxxxxxx> wrote:~~~~~~~~~~
The default graphical package manager for a given software type must appropriately:
* install, remove and update software, even if multiple operations are scheduled sequentially or concurrentlyI am definitely against blocking on "multiple operations concurrently". I don't see this as a frequently used "blocking material", I'd rather leave this can of races unopened.
I'm not sure if you understood it correctly (or if I even expressed it correctly). The operations are of course executed sequentially, always (that's how our package managers work). But they can be *scheduled* concurrently, i.e. you can install GIMP, and before it is downloaded and installed, you can also schedule installation of Inkscape. I think this is not an unusual use case, to schedule several operations at once. E.g. I just installed a new system and want to install my favorite applications. Or I decided that I want to play a different game, so I hit Install on OpenArena and also click Remove on SuperTuxKart.
Is this really what you are against, or have you understood it differently? I can try to phrase it better.
Now that you made the point, I now realize that there *is* really a case where multiple operations can be *executed* concurrently. If you schedule installation of an RPM and a Flatpak at the same time, they are performed concurrently (tested with GNOME Software). So we could rule those out and say this is a case when it's not blocking. But honestly, this is a very small technical distinction that we're able to make (sequential RPMs versus concurrent RPM+Flatpak), but our users won't. And now that we have Flatpaks even in official Fedora, and they are even selected by default in GNOME Software, our users will start to hit this use case more and more frequently. I think it would be weird to say "we block on gnome-software blowing up if you press Install on these two packages (before the first operation is finished), but we don't block if you do the same thing on these other two packages (because one of them is an official Flatpak)". I'd rather just cover both cases. It's not like we don't have experience with race conditions (this very cycle!), and if it is hard to reproduce or hard to fix, then it's just the usual "shrug, sorry" approach as always.
Apart from that, I am slightly against blocking on "sequentially".
See my response above. Imagine that we'd ensure only the first dnf operation works correctly, but any later one can blow up. Why would we want to allow that with a graphical package manager?
* start the selected installed softwareIf the Graphical package manager exposes such a feature.
Sure, exactly as the footnote says. Or do you have a better phrasing for the footnote to make it even clearer?
Others seem fine, thanks for summarizing this into a more formally defined criterion.
Thanks.
One more note though, can you post this to the desktop and kde lists (or tickets) for their opinions? This shouldn't be put into effect unless our blocking desktop maintainers agree imo. For example, KDE folks might want to block on a smaller subset of this criterion (I don't know if they do).
Sure, I will. I wanted to fine-tune it in the test list first, though.
_______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
