FS#58524 - [discover] Make packagekit-qt5 a required dependency so that it finds apps by default
Attached to Project:
Arch Linux
Opened by Nate Graham (pointedstick) - Wednesday, 09 May 2018, 14:34 GMT
Last edited by Antonio Rojas (arojas) - Thursday, 10 May 2018, 06:59 GMT
Opened by Nate Graham (pointedstick) - Wednesday, 09 May 2018, 14:34 GMT
Last edited by Antonio Rojas (arojas) - Thursday, 10 May 2018, 06:59 GMT
|
Details
Without packagekit-qt5 being a required dependency, Discover
has no ability to search for apps by default, and Arch users
complain that Discover is useless and doesn't find anything.
Well, not until it has at least one backend for apps!
|
This task depends upon
Closed by Antonio Rojas (arojas)
Thursday, 10 May 2018, 06:59 GMT
Reason for closing: Won't implement
Thursday, 10 May 2018, 06:59 GMT
Reason for closing: Won't implement
- silently updates pacman databases behind the user's backs (essentially doing pacman -Sy, which is highly discouraged), which can cause breakage in subsequent pacman operations for inexperienced users
- hides pacman output (post-install messages and optional dependencies) which are an essential part of an Arch system maintenance.
Until these issues are addressed in the alpm packagekit backend and in discover itself we can't even consider pulling PK as a dependency of Plasma. It is already an optional dependency, so users who read pacman output (as they should) know what to do to add repository packages support.
Can you file an upstream bug for Discover asking that it show post-install messages when the PackageKit backend is pulling from Arch repos?
The only supported way of installing and updating system packages on Arch is with pacman via the command line. We don't want to stop users from using other ways if they wish to (that's why we're providing the PK backend), but we don't want to encourage it either. As I said, it is an optional dependency, so it is displayed by pacman in post-install and users who know what they're doing can install it (users who don't read pacman output don't qualify as "knowing what they're doing" and would probably run into issues with packagekit).
As for things that are missing in the PK/Discover UI: ability to display post-install output and optional deps, ability to show prompts when there is a package replacement or conflict (instead of silently accepting the default), ability to show update errors..., AFAIK none of it is implemented in the alpm PK backend yet, until that happens there's not much that can be done on the discover side.
Essentially, my point is that the overlap betweeen "Users who know what they're doing" and "Users who are interested in Discover" is very small. Anyone who's attracted to Discover is a person who wants to be protected from having to know most of the techincal details. Maybe these users are not ideal Arch users. But as long as they *are* Arch users, they should either get the user experience they're looking for, or be discouraged from using Discover. IMHO.
So I would edvocate for one of two outcomes:
- Stop automatically installing Discover from Plasma so that non-ideal-Arch-users who wants to be protected from technical details aren't shown an an option that's discouraged and doesn't work well out of the box
- Make Discover and PackageKit first-class citizens so that they're fully supported
Does that make sense?
...
I'm not sure why you seem to hate this idea.
I understand the situation is not ideal (and you may be getting some bogus reports from some users because of this), but this would cause more harm than good and Arch users are expected to be able to deal with optional dependencies.