On Mon, Nov 8, 2021 at 3:05 PM Kamil Paral <kparal(a)redhat.com> wrote:
"dnf install foo bar"
This is a single operation, comparable to having multiple packages
installed via graphical package manager, not scheduling multiple operations
at once. It would be the same If a graphical package manager offered to
select multiple packages/applications and then start the transaction.
"dnf install foo; dnf install bar"
This is equivalent to:
1. Open Graphical package manager
2. Install foo
3. Close Graphical package manager
4. Open Graphical package manager
5. Install bar
6. Close Graphical package manager
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:
https://pagure.io/fedora-qa/blocker-review/issue/560
dnf exits after transaction finish, so it's equivalent to a workaround that
was possible for that blocker proposal. Also, I might've added that I'd
block on this once we agree on proper criterions ;)
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?
Are users doing this? I don't think so, you think they do. We don't have
any data we can use to say which way it is used. Nothing prevents you from
testing this path and reporting bugs and working with the devs on solving
it, even if it isn't a blocking path.
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 don't do this, I've never seen anyone (with or without a technical
background) do this. All the users I've seen do is to wait until something
finishes and then switch to other tabs/sections, etc. Again, I am not
saying this isn't happening, all I am saying it's not blocker material, in
my opinion.
--
Best regards / S pozdravem,
František Zatloukal
Quality Engineer
Red Hat