Progress console in Discover

DrKonqi has a console. It’s damn useful, because a GUI which interfaces so directly with CLI applications like gdb can’t feasibly (and probably has no need to) cater for every eventuality.

However, this also describes Discover:

  1. `.rpm` package header not signed. · Issue #479 · browsh-org/browsh · GitHub
  2. `.rpm` package header not signed. · Issue #759 · rmcrackan/Libation · GitHub
  3. `.rpm` package header not signed. · Issue #1101 · veracrypt/VeraCrypt · GitHub
  4. `.rpm` package header not signed. · Issue #954 · mucommander/mucommander · GitHub

Being able to simply hit y here would remediate all of these, meaning significantly less work for package developers, and less confusion for users.

Another incredibly common situation in which this matters is during every update. Specifically, after installation, should I want to know what was installed before I reboot, I have to open the “More information” section before the update and leave Discover (a single-instance application) open until it completes:

By the way, weirdly, this can’t be opened during installation:

…despite this demonstrating that nothing fundamentally prevents it.

Even with this hack, the GUI doesn’t provide much useful information about what was completed during the update, when compared to a log from zypper or dnf.

Just using the konsole KPart as a panel like dolphin does would be a massive improvement. However:

1 Like

Please read what Discover isn’t:’t


@rockandstone, why do you link that?

Because it explains you what Discover isn’t.

@rockandstone, I’m obviously not going to be any the wiser from a response like that. I’ve read it, so I know what it’s about. I’m asking for an explanation of how it relates to this.

Probably because “It is not a replacement intended to compete with the terminal for experienced expert users.” would suggest that your idea is pretty far out of scope for Discover.


@ngraham, I thought that at least

had merit, considering that currently, a rather nondescript error is supplied to the user which isn’t immediately actionable.

I can quite easily imagine this frustrating someone, since on Windows, whether a package is signed or not doesn’t affect installation (unless it’s an MSIX package, in which case there is no way to bypass it, so it’s a moot point, because consequently, nobody distributes them in that state).

It would be. But:

  1. PackageKit doesn’t support this.
  2. PackageKit is unlikely to accept this change. As Redhat sees Flatpak as “the future of application distribution”, and Flatpak, like other modern “appstores”, doesn’t ask questions when installing apps. So PackageKit is just a legacy that no one wants to do any significant change with.
  3. KDE doesn’t have the manpower to develop its own package manager abstraction layer for this. And shouldn’t.


@jinliu, yeah, I’ve read PackageKit is dead, long live, well, something else – Technical Blog of Richard Hughes too. However, I’ve also been told multiple times that

I don’t think I’ve seen a single comprehensive document explaining exactly whether, and if so, how, PackageKit is deprecated. All the information I’ve found is conflicting.

Heck, I’ve even had a few productive conversations at PackageKit’s GitHub repository, so it’s definitely at least managed in some respect.

Yeah. It’d be silly to, considering that lots of other stakeholders, like GNOME, also want a usable backend, and nobody has any desire to create a proprietary implementation.

This is just [Question] Add ability to resolve package conflicts interactively? · Issue #604 · PackageKit/PackageKit · GitHub all over again.

PackageKit maintainers don’t want to do it, so the ball is on distros to not implement their PackageKit plugins in a way that relies on an intentionally absent feature.

If they don’t want to do that, they should write their own custom backends for Discover that implements the interactivity that they they feel is important to prompt the user with.

If they don’t have the desire or resources to do that either, then the result is what you see: users getting tortured by the “His fault! No her fault! No his fault!” game. There is nothing KDE can directly do to fix it.

1 Like

Apart from that, Discover offers packages already signed and present (and tested) in distro’s repos guaranteeing this way a more stable system. Why should it accept “external” keys from whatever github repos and software to be installed locally, with all the dangers that are associated with unverified software, potential extra dependencies or multiple libraries that are a liability for the system, when its design philosophy is not being actually an alternative “hard-core” package manager GUI, but a storefront showcasing and easy-installing the software available in the distro to begin with.

The point is that it’s not up to Discover. This situation arises because adventurous users add lots of 3rd-party repos that their own distros’ PackageKit plugins aren’t able to properly handle. All the action for supporting this happens at a level below what we control in Discover.


Thanks, @ngraham. I’ll take this up with Fedora and openSUSE then, if it hasn’t been discussed and/or reported yet in the relevant places.

Indeed. To my knowledge, this has solely occurred when installing unsigned RPMs directly (regardless of whether I’ve added a repository for it).

It’s a discussion that has been had approximately five million times. It will probably go something like this:

Distro maintainers: “PackageKit just needs to implement interactivity; we need that feature!”

PackageKit folks: “Not on the roadmap; plugins should choose a default safe option instead of nagging the user.”

D: “The default safe option is often not what the user wants, though; In cases where there’s a file conflict or an untrusted signature, the default safe choice will be to block the package from installing, which is what we do right now and people are complaining about it.”

P: “Then do what the user asked even if you consider it to be unsafe.”

D: “This is too dangerous; the user needs to be informed of the risk of what they’re doing.”

P: “Maybe, but not at the level of PackageKit. If the user can do dangerous things, they should be warned about it before the moment they finalize the transaction. By that point it’s really too late.”

D: “Maybe, but that’s out of our control since PackageKit doesn’t provide a way for us to write such functionality into our plugin. It would need to be done in app stores like KDE Discover and GNOME Software.”

P: “Then work with them to do that.”

D: “But we aren’t familiar with those codebases. We don’t know GTK/Qt/C/C++/QML/etc and we aren’t GUI app devs. It’s also not clear what actually does constitute a 3rd-party repo from the perspective of those apps. PackageKit doesn’t make this distinction. We just want PackageKit to offer the same workflow people get when they use the command-line package manager.”

P: “The command-line package manager offers a garbage UX, which is why we aren’t replicating it. Grandma can’t be trusted to use sudo apt upgrade.”

D: “Right, but grandma isn’t the one adding untrusted packages to her system. It’s her nerdy granddaughter who’s doing this.”

P: “Then the nerdy granddaughter should use the command-line package manager for herself if she likes to live dangerously. And if it’s for her grandma’s computer, she shouldn’t tinker with the repos at all.”

D: “But she needs to add 3rd-party repos to get DVD decoding and media codecs working so grandma can watch movies, which exposes grandma to this problem.”

P: “That sounds like a you problem. Just ship that stuff in your main repo.”

D: “We can’t due to legal risk.”

P: “Then maybe you should coordinate more closely with those repos so there are never file conflicts or untrusted signatures and the problem never happens.”

D: “Still too much legal risk, sorry.”

P: “Ubuntu manages to get away with having one checkbox in their installer to do this and they’re a big company. Why can’t you do the same thing?”

D: “We asked our lawyers the same question and they told us Canonical is taking on a level of legal risk to do this that they’re not comfortable with us taking on. So we just can’t do it, sorry.”

P: “Well, then you’re boned. I’m sorry too.”

This has been “PackageKit: A Drama in One Act”

1 Like

@ngraham, do you see any way out of this catch-22, even theoretically? That’s a depressing state of affairs. Again, many thanks for explaining it so verbosely.

If the Solution plugin were available here, I’d set that as the solution.

The only feasible approach I see is for the distros that want to use interactivity during package update or installation to abandon the use of PackageKit entirely and provide Discover with a custom backend capable of prompting for interactivity in this way. Discover already has custom backends for SteamOS and Fedora Kinoite, so this isn’t as impossible as it may sound.

However it’s still a lot of work and someone who uses the so-supported distro would need to maintain that code. Ideally someone from the distro itself. And of course it requires someone in the distro to care enough about Discover to build such a thing in the first place, since it wouldn’t be code that’s shareable with GNOME Software. This is why the only two custom backends Discover has are from KDE-only distros whose maintainers don’t care about GNOME.

1 Like

@ngraham, and you think that that’s more (at least, immediately) feasible than someone superseding or forking PackageKit?

I have no idea. Any of those options would most likely take place out of KDE, and be done by people who aren’t KDE developers.

1 Like