On Thu, Nov 4, 2021 at 3:02 PM Frantisek Zatloukal <fzatlouk@xxxxxxxxxx> wrote:
On Thu, Nov 4, 2021, 11:40 Kamil Paral <kparal@xxxxxxxxxx> wrote: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.Yeah I understood it correctly. I am not saying it's not a valid use case, just that I don't think that it's a common enough use case to be made blocking.
I replied to Ben regarding this, please read that response, thanks.
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?You can't schedule multiple dnf operations at once.
"dnf install foo bar"
"dnf install foo; dnf install bar"
It depends on what your definition of an operation is. But in both cases, I don't see a functional difference between these and a user clicking on the Install button for foo and bar in the graphical package manager.
Doing a single installation, waiting for it to finish, then doing another is something you can do with dnf and something that I'd block on with graphical package managers.
And yet you voted for a RejectedBlocker just a few weeks back:
If you changed your mind, great :-)
Scheduling multiple tasks without waiting for them to finish one by one is something that I am against blocking on.
What purpose does it make to punish users for something they can't know? They don't know that they should wait for the first operation to finish, and only then click on the next button. This way they are safer, because they are within the path we block on (if we used your definition). So why do we even allow them, *tempt them* to be able to click a different button in the meantime? Shouldn't we push on developers to prevent simultaneous button clicking?
And I'm going to go down the rabbit hole even more. How is scheduling another install different from e.g. listing installed packages or available updates? If the user starts installation of package A, and then switches to the Installed or Updates tab in gnome-software (which executes a *concurrent* packagekit operation), and then the whole thing breaks, do we also say "you naughty human being, you shouldn't have clicked that, even if we allowed you to" and not block on it?
I'm making fun of it a little. But overall, graphical apps are (and supposed to be) interactive, which demands a different approach in certain areas. In a file manager, would you also argue that the user must not click anything until a file operation is finished? In picture viewer, that a photo can't be advanced until the current one if fully loaded? In a web browser, that a tab can't be switched until the webpage is fully loaded? You'll say "but that's much more common". Yes, perhaps. But at the same time, a package manager working correctly is probably the most important one of all of that. So it's not just about the common paths (many of our criteria aren't).
_______________________________________________ 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
