Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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
Task Type General Gripe
Category Packages: Extra
Status Closed
Assigned To Antonio Rojas (arojas)
Architecture All
Severity Very Low
Priority Normal
Reported Version 5.0.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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
Comment by Antonio Rojas (arojas) - Wednesday, 09 May 2018, 15:46 GMT
This is a big no-go, sorry. Packagekit is a very intrusive piece of software and should only be installed on demand by users who know what they're doing. Among other things, it
- 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.
Comment by Nate Graham (pointedstick) - Wednesday, 09 May 2018, 15:55 GMT
The problem is, Discover is somewhat useless without that package. I would expect that a user who installs Discover is implicitly signaling their acceptance of those trade-offs. Why else would they install Discover in the first place? The venn diagram of users who want to use Discover and users who don't want to use PackageKit has very little overlap.

Can you file an upstream bug for Discover asking that it show post-install messages when the PackageKit backend is pulling from Arch repos?
Comment by Antonio Rojas (arojas) - Wednesday, 09 May 2018, 16:29 GMT
Most users don't install discover by itself, but as part of the Plasma group. Out of the box it works as a central point for installing all kinds of plasma addons, so I wouldn't call it useless (plus there's also the flatpak backend).

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.
Comment by Nate Graham (pointedstick) - Wednesday, 09 May 2018, 16:39 GMT
All the addons available via Discover are also available via the Get Hot New Stuff UI from within the apps/KCMs themselves.

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?
Comment by Eli Schwartz (eschwartz) - Wednesday, 09 May 2018, 16:59 GMT
- Keep the status quo, offering Discover primarily as a central place to install addons.

...

I'm not sure why you seem to hate this idea.
Comment by Eli Schwartz (eschwartz) - Wednesday, 09 May 2018, 17:01 GMT
  • Field changed: Task Type (Bug Report → General Gripe)
  • Field changed: Summary (Make packagekit-qt5 a required dependency for package discover so that it finds apps by default → [discover] Make packagekit-qt5 a required dependency so that it finds apps by default)
  • Field changed: Status (Unconfirmed → Assigned)
  • Field changed: Category (General → Packages: Extra)
  • Field changed: Architecture (All → All)
  • Field changed: Severity (Low → Very Low)
  • Task assigned to Antonio Rojas (arojas)
expecting this to be a wontfix/deferred
Comment by Nate Graham (pointedstick) - Wednesday, 09 May 2018, 17:20 GMT
I don't hate it, I'm just trying to improve the user experience for Arch users who expect Discover to work "out of the box". Perhaps the real answer here is that a person who wants to use Discover and expects it to work out of the box shouldn't be an Arch user...
Comment by Tommy Schmitt (spinka) - Wednesday, 09 May 2018, 19:21 GMT
I'm against this. I use discover for flatpak and it fills my usecase without packagekit installed. I don't want to be forced to install packagekit backend. Snaps are probably similar case. It's weird to me that Discover developer doesn't know that his app can be used without packagekit. Optional dependencies are the right target here. Users who can't handle optional deps indeed will have much trouble using Arch.
Comment by Antonio Rojas (arojas) - Thursday, 10 May 2018, 06:59 GMT
"Anyone who's attracted to Discover is a person who wants to be protected from having to know most of the techincal details." - And my point is that such users should by no means be using packagekit on Arch. As I said, packagekit silently updates pacman's databases - if a user then installs some package without updating their system first, they will end up in a partially updated state, which depending on the timing can lead to several different degrees of breakage. We are not going to make it easier for users to shoot themselves in the foot. That's the same reason why we don't ship any pacman GUI or AUR helper in the binary repos.

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.

Loading...