Moving to Neon as this is an AppStream misconfiguration issue.

*** Bug 451330 has been marked as a duplicate of this bug. ***

Cannot reproduce.

Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.25.80
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.5
Graphics Platform: Wayland

Created attachment 179329 [details]
Discover not finding deb apps

Hi, I'm sorry for reviving an old bug, but I'm having this issue on Kubuntu 24.10 with backports PPA enabled, using Plasma 6.1.5. Deb packages available for installation with apt install do not appear when searching for them on the Discover app. For example:

$ apt-cache search heimdall
heimdall-flash - tool for flashing firmware on Samsung Galaxy S devices
heimdall-flash-frontend - tool for flashing firmware on Samsung Galaxy S devices - Qt GUI

But when searching for heimdall-flash in Discover, it isn't found (see attachment).

It's not a Discover bug; it's an intentional packaging decision in Neon to hide apps from the distro repos from Discover. The intention is for people to use Discover to get apps from Flatpak or Snap. There's nothing Discover can do about this.

(In reply to Nate Graham from comment #6)
> It's not a Discover bug; it's an intentional packaging decision in Neon to
> hide apps from the distro repos from Discover. The intention is for people
> to use Discover to get apps from Flatpak or Snap. There's nothing Discover
> can do about this.

But my issue is on Kubuntu 24.10 with the backports PPA enabled, or is it an upstream decision? also, I'm curious in what's the logic behind that decision? there are plenty of deb packages which aren't available as snaps or flatpaks that would be undiscoverable to new users not familiar with the Debian packaging tools.

Ah my apologies, I skimmed and totally misread your comment, wasting both of our time. :(

The actually correct answer is that Discover is not a graphical package manager; it's an "app store" and only shows software that advertises itself using AppStream metadata. Evidently heimdall-flash does not. If that package provides a GUI app, then it probably should have some AppStream metadata. If it does not provide a GUI app, then nobody is at fault, and rather the issue is a disconnect between what Discover is intending to do and what you were hoping to use it for. :)

heimdall was just an example, with the one that I came to realize this behavior, but probable there are plenty other packages. I, as an user I would expect to be able to find all available software in the app store from all configured sources in my system, no just the ones with a GUI or a flatpak or snap package, I don't see the advantage of leaving out the deb packages, but those are just my 2c.

Then I would recommend that you find a graphical package manager app that suits your needs and desires. Synaptic is a common one for Debian-based distros.

But Synaptic is for installing deb packages only, my point is why not have a single interface for all software sources? what's the reasoning behind that decision? IIRC, Discover did not behave like this always.

Searching I found a package called plasma-discover-backend-packagekit, that as I understand it, it should provide support for distribution packages. The curious thing is that if I search for it on Discover, it seems to be already installed because I can see the remove icon (the trash can), but I cannot find it installed as a snap, flatpak or deb package.

Based on the versions listed on https://apps.kde.org/discover.packagekit/, it seems it is available with Plasma 6.3?

The package you found provides Discover with the ability to interact with distro packages, but only install and remove the ones with AppStream metadata, like I mentioned earlier.

To my knowledge, Discover has always been an "app store" and not a graphical package manager.

This is all getting pretty out of scope for a closed bug report.

(In reply to Juan Luis Baptiste from comment #11)
> But Synaptic is for installing deb packages only, my point is why not have a
> single interface for all software sources? what's the reasoning behind that
> decision? IIRC, Discover did not behave like this always.

Hi Jean Luis
In neon we run an mgmt_appstream-generator_noble_user which creates the neon archive appstream metadata for the packages we produce.  https://build.neon.kde.org/job/mgmt_appstream-generator_noble_user/
Then we have  a mgmt_appstream-ubuntu-filter_noble job which filters out the packages we provide from the ubuntu archive metadata so discover doesn't display duplicates.  https://build.neon.kde.org/job/mgmt_appstream-ubuntu-filter_noble/
The filter job also only adds desktop-app & desktop-application appstream component kinds so as to not overload discover with irrelevant entries.  https://invent.kde.org/sysadmin/neon-tooling/-/blob/master/nci/appstream_ubuntu_filter.rb?ref_type=heads
The comments in that file are from 2020 and could possibly do with reviewing.  One could argue that web-app/web-application deserve to be not filtered in the modern day.
I assume that Kubuntu has a similar setup, maybe @rikmills knows more about this topic ??

(In reply to Juan Luis Baptiste from comment #9)
> heimdall was just an example, with the one that I came to realize this
> behavior, but probable there are plenty other packages. I, as an user I
> would expect to be able to find all available software in the app store from
> all configured sources in my system, no just the ones with a GUI or a
> flatpak or snap package, I don't see the advantage of leaving out the deb
> packages, but those are just my 2c.

heimdall-flasher does not have appstream data nor a .desktop file included in it's source - https://github.com/Benjamin-Dobell/Heimdall/tree/master/heimdall-frontend
fedora patch one in as part of their packaging process so that it will show up in discover - https://src.fedoraproject.org/rpms/heimdall/tree/rawhide

Hi guys,

Thank you for the insightful answers, I just wanted to understand the reasoning behind not displaying available software from all available sources, independent if they are a gui app or whatever. I now understand the technical requirement of needing appstream metadata for an app to be displayed on Discover, but I still wonder why packages that do not have it should end up "hidden" from an app like Discover, which is the go-to option for an user that wants to install any software using the desktop's GUI.