On Thu, Nov 4, 2021 at 2:19 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote:
On Thu, Nov 4, 2021 at 6:12 AM Kamil Paral <kparal@xxxxxxxxxx> wrote:
>
> "Multiple operations" is one of the reasons for proposing this criterion. In this release, and previous releases, we often had a bug that you can install a package, but then you can't remove it. But if you restarted the package manager, or your session, then it worked. And people said "well, both install and remove work, you just can't use them together, so... it's fine according to the criteria!". That's why I list it explicitly as blocking Final. I don't think it's fine.
>
I guess my question comes down to is this something The Average User™
does, or is it just something that Kamil does because he's really good
at QA? If it's the former, then I'm in favor of your proposal.
> Another scenario could be when you hit Install on app A, and before it is done, you hit install on app B. Imagine if the first operation would get stopped abruptly. The same argument could be used as above (which is a real argument, not a made-up one). Again, that's why I mention it explicitly.
>
I see that as being a different case from the above, and I would
definitely support blocking on that behavior. The only thing that
should abruptly stop a transaction is the user hitting a cancel
button. So while I'm still unclear about the first part, I'm totally
on board with this part.
I find it hard to draw the line somewhere between all these cases. So aborting a previous operation is not ok, but not even starting a second operation is ok? Installing and removing the same package is not blocking? What about installing two different packages, would that block? What about installing A and removing B? I don't honestly think it's a good idea to dig into the million of sub-cases here.
Just imagine we're not talking about the package manager but a file manager instead. If you could either create a file, or remove a file, but you couldn't create&remove the file, or you couldn't remove 2 different either sequentially or together, that would clearly be a blocker (I hope). It would be quite obvious that this is a basic functionality. So why isn't this a basic functionality for the package manager? And why do we have (it seems) a different quality bar for dnf vs graphical package managers? I don't think these bugs would be waived for dnf.
I can't speak for the mythical average user, but yes, I believe performing multiple operations in a single session is quite common. Like installing 2 different applications. Or to provide a real-world example, my father likes to play some chess. And so he searches gnome-software for "chess", installs the first app in the result list. He doesn't like it much, so he removes it and installs the second one. I really don't buy that this is not a common enough scenario (replying to Frantisek here as well).
Actually, the fact that gnome-software has been so broken in the past, forced my father to learn some dnf commands. Last week, a non-IT colleague in the office asked me "what the magical command to update the system was, once more?" because gnome-software was stuck again. I personally don't use gnome-software on my home computer, ever. One reason is that I prefer to be in control and see all the text output of dnf, but the second reason is that I don't trust it enough. And I don't think it's ok. I consider gnome-software and PackageKit (it's hard to separate the two and point fingers exactly) to be one of the biggest problems in Fedora Workstation. They are *very* unreliable for the end user, and their problems are extremely hard to debug and almost impossible to reproduce for power users like us. If we don't attempt to improve the situation, it won't. And if we keep saying that it's ok to not be able to install and remove a package in the same session, then I believe Fedora is only suitable for people who don't rely on these tools, like you, or me, or probably most people in this discussion. But not for others.
(To be clear, I don't want to belittle all the work that gnome-software/packagekit developers have done in the past. Especially this cycle, we squashed many gnome-software related bugs, and Milan, the main developer, has been very helpful and active. I'm just stating the fact that graphical package management is unfortunately what I see as the most unreliable part of our desktop).
>> We should clarify this to something like "list software installed from
>> managed repositories". The wording probably needs help, but the idea
> What about:
> * list locally-installed software coming from the official Fedora repositories
> ?
Well, I think we'd want it to work for other repositories too (like
Flathub, rpmfusion, etc). But there's a case for keeping the criterion
limited to just the official repos because if something fails because
a third-party repo does something weird, that's out of our control. So
I guess this wording works if only to prevent ourselves getting hung
up on a totally-out-of-our-control bug at some point in the future.
Agreed. This is the minimal set that we block on, but of course we prefer the tool to be more functional than just the minimal set.
>> Do we want to make it clear that it's not intended to allow the user
>> to *add* a new repository? Or is that understood?
>
> GNOME Software doesn't allow the user to add any additional repository. KDE Discover allows the user to add an arbitrary Flatpak repository, or Flathub directly with a specialized button. My idea was to not distinguish between different buttons, simply if it is present and serves for repo configuration, it must work. However, if you think it's better, we can exclude the Add button explicitly, or we can name which exact buttons/operations must work.
>
I'm on board with the enable/disable part for sure. I'm not sure how I
feel about the adding new repos part. I think I'm weakly opposed to
including it. One, it adds to the number of things we need to test.
Two, and more importantly, most third-party repos that I've come
across provide an RPM or similar to add a new repo. And if for some
reason it doesn't work via the GUI tool, I think saying "sorry, do it
on the command line then" is reasonable for this particular use case.
I think I agree with you. Enabling/disabling pre-defined repos is the most important part here. Adding a repo is nice to have, but we don't need to guarantee it, because everything we officially support and block on is already provided with the pre-defined repos. Additional repos only extend that with unofficial packages, and so there's nothing lost from the officially supported set, if the adding functionality is broken (also, that functionality is mostly not present in our current package managers anyway). Deleting a repo is not that important, if you can disable it. KDE Discover offers "setting a default source", i.e. switching whether RPMs or Flatpaks should be installed by default (if the app exists as both). But I think that's a quite minor feature that doesn't need to be blocking.
So let's reduce the original requirement into something like this:
* configure software sources by enabling/disabling pre-defined official repositories and then adjust the available software pool
accordingly
Does it sound better?
_______________________________________________ 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
