Bug 504799 - With default source set to PackageKit backend, apps found via search (not browse) have non-default source prioritized
Summary: With default source set to PackageKit backend, apps found via search (not bro...
Status: RESOLVED FIXED
Alias: None
Product: Discover
Classification: Applications
Component: discover (other bugs)
Version First Reported In: 6.3.5
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2025-05-26 06:10 UTC by EpicTux123
Modified: 2025-10-04 14:56 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In: 6.5.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description EpicTux123 2025-05-26 06:10:11 UTC
When searching on Plasma Discover, it seems that some apps only have appstream data for their Flatpak version.

Sometimes, Discover shows both the system package and the Flatpak version as separate apps (duplicate entries), and sometimes it only shows one of them.

However, for some apps that have only one entry type (system package or Flatpak), after acessing its page, Discover suddenly knows there is also the other format available for download (I can then select "From Fedora Linux" or "From Flathub").

My suggestion is that, after Discover suddenly knows about the existence of the new format, it should prioritize what the user has set as the Default Source in Discover's Settings.

===================

EXAMPLE

My default source is system packages (RPM format).

I search for "Firefox" in Discover, and I only get the Flatpak version in the results.

I click to view its details, and it comes as a package "From Flathub", even though my default source is system packages.

EXPECTED RESULT

Package should be "From Fedora Linux", if available, even though only the Flathub app appeared in the search results.

OBSERVED RESULT

Package is from Flathub, not respecting default source.

===================

Operating System: Fedora Linux 42
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.0
Kernel Version: 6.14.6-300.fc42.x86_64 (64-bit)
Graphics Platform: Wayland
Comment 1 EpicTux123 2025-05-26 06:11:05 UTC
Additional comment: I think this is not Discover's fault, but rather the appstream data that is incomplete. However, since Discover is able to suddenly know the existence of another format after acessing the app's page, then this workaround I suggested could be done as well (I believe so).
Comment 2 Nate Graham 2025-05-27 22:56:24 UTC
Actually it's fine, I can reproduce this on Fedora 42 as well, with everything KDE built from source.
Comment 3 Akseli Lahtinen 2025-09-29 14:28:05 UTC Comment hidden (spam)
Comment 4 Aleix Pol 2025-09-29 22:23:06 UTC
I get this error at times:
 OdrsReviewsBackend::fetchReviews fetchin... "org.mozilla.firefox" "{\"app_id\":\"org.mozilla.firefox\",\"distro\":\"Arch Linux\",\"limit\":-1,\"locale\":\"en_US\",\"user_hash\":\"119e5969aa784aebca3ee48b3d125e35e3efb92c\",\"version\":\"143.0.1\"}"
 org.kde.plasma.libdiscover: OdrsReviewsJob::reviewsFetched|?libDiscoverCommon.so?|?libDiscoverCommon.so? OdrsReviewsBackend: Error fetching reviews: "Error transferring https://odrs.gnome.org/1.0/reviews/api/fetch - server replied: " "<!DOCTYPE html>\n<head>\n    <base href=\"//error.c.cdn77.org/\" target=\"_blank\">\n    <meta http-equiv=\"Content-Type\" content=\"text/html; charset=utf-8\">\n    <meta name=\"author\" content=\"(c) 2023 CDN77\">\n    <meta name=\"description\" content=\"\">\n    <meta name=\"keywords\" content=\"\">\n    <meta name=\"viewport\" content=\"width=device-width, initial-scale=1\">\n    <meta name=\"robots\" content=\"nofollow\" />\n    <link rel=\"stylesheet\" href=\"css/main.css\">\n    <link rel=\"shortcut icon\" href=\"img/favicon.ico\" />\n\n    <title>Website is offline \xE2\x80\x93 Gateway time-out</title>\n</head>\n<body>\n    <header class=\"Header\">\n        <div class=\"Header-wrap\">\n            <span class=\"Header-errorNumber\">Error 504</span>\n                        <h1 class=\"Header-title\">Gateway time-out</h1>\n            <div class=\"Header-description\">CDN77 server haven't received a timely response from origin server.</div>\n            <img src=\"img/error-scheme.png\" alt=\"Gateway time-out\" class=\"Header-scheme\">\n        \n        </div>\n    </header>\n    <section class=\"Section Section--errorBottom\">\n        <div class=\"Section-wrap\">\n                        <div class=\"WhatToDo\">\n                <div class=\"WhatToDo-column\">\n                    <h3 class=\"WhatToDo-title\">If you're a <strong>Visitor...</strong></h3>\n                    <div class=\"WhatToDo-description\">\n                        <p>Please try again in a few minutes. If the problem persists for more than 30 minutes, try contacting website owner via a different channel.</p>\n                    </div>\n                </div>\n                <div class=\"WhatToDo-column\">\n                    <h3 class=\"WhatToDo-title\">As the <strong>Website administrator...</strong></h3>\n                    <div class=\"WhatToDo-description\">\n                        <p>Take a look at the article on <a href=\"https://client.cdn77.com/support/knowledgebase/cdn-resource/troubleshooting-error-messages\" class=\"common-link\">troubleshooting error messages</a> in our knowledgebase.</p>\n                    </div>\n                </div>\n            </div>\n        \n        </div>\n    </section>\n</body>\n"
 OdrsReviewsBackend::fetchReviews fetchin... "org.mozilla.firefox" "{\"app_id\":\"org.mozilla.firefox\",\"distro\":\"Arch Linux\",\"limit\":-1,\"locale\":\"en_US\",\"user_hash\":\"119e5969aa784aebca3ee48b3d125e35e3efb92c\",\"version\":\"143.0.1-1\"}"
 OdrsReviewsBackend::fetchReviews fetchin... "org.mozilla.firefox" "{\"app_id\":\"org.mozilla.firefox\",\"distro\":\"Arch Linux\",\"limit\":-1,\"locale\":\"en_US\",\"user_hash\":\"119e5969aa784aebca3ee48b3d125e35e3efb92c\",\"version\":\"143.0.1\"}"
 OdrsReviewsBackend::fetchReviews fetchin... "org.mozilla.firefox" "{\"app_id\":\"org.mozilla.firefox\",\"distro\":\"Arch Linux\",\"limit\":-1,\"locale\":\"en_US\",\"user_hash\":\"119e5969aa784aebca3ee48b3d125e35e3efb92c\",\"version\":\"143.0.1-1\"}"

That's simply the server failing.

Also I see that since we use the packaging versioning we get weird results. I'll submit an MR to always use versions from AppStream.
Comment 5 Akseli Lahtinen 2025-09-30 08:06:41 UTC
Seems I've been replying to wrong reports 😩 Ignore my earlier comment
Comment 6 Aleix Pol 2025-09-30 15:27:33 UTC
Git commit 7f2c06c1175781fc3998927b9759e87885b2195d by Aleix Pol.
Committed on 30/09/2025 at 15:09.
Pushed by apol into branch 'master'.

flatpak: Fix searches

Do not triage away the items that were provided by the appstream pool.

We might be missing important things.
To reproduce the issue: `plasma-discover --backends --search "mozilla
firefox"`

M  +8    -4    libdiscover/backends/FlatpakBackend/FlatpakBackend.cpp

https://invent.kde.org/plasma/discover/-/commit/7f2c06c1175781fc3998927b9759e87885b2195d
Comment 7 Aleix Pol 2025-09-30 15:28:14 UTC
Git commit 2eafccaf3b60cfd51d1fcc5ca6ffadaf396e8dde by Aleix Pol.
Committed on 30/09/2025 at 15:27.
Pushed by apol into branch 'Plasma/6.5'.

flatpak: Fix searches

Do not triage away the items that were provided by the appstream pool.

We might be missing important things.
To reproduce the issue: `plasma-discover --backends --search "mozilla
firefox"`

M  +8    -4    libdiscover/backends/FlatpakBackend/FlatpakBackend.cpp

https://invent.kde.org/plasma/discover/-/commit/2eafccaf3b60cfd51d1fcc5ca6ffadaf396e8dde