When an update is started that targets Flatpaks, and a Polkit dialog is displayed to authorize changes to those, Discover fails with "Flatpak system operation Deploy not allowed for user" before the user even has a chance to finish typing the password. STEPS TO REPRODUCE 1. Launch Discover in a distro that has Flatpak's Polkit rules configured to ask for a password. 2. Start the update process when Flatpak updates are available. OBSERVED RESULT The update fails with an error for every Flatpak app before the Polkit dialog is interacted with. EXPECTED RESULT The user enters their password peacefully, and only then Discover attempts the update. SOFTWARE/OS VERSIONS Operating System: openSUSE Leap 15.4 KDE Plasma Version: 5.27.1 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Graphics Platform: Wayland ADDITIONAL INFORMATION
seems bad
I think what actually happens there is that it throws up an auth dialog for package0 and then moves on to package1 and that also needs an auth dialog but instead of waiting it just moves on with access denied. Seems a very niche way to setup flatpak since one basically has to individually authenticate every single update I think
I wouldn't call it niche when it's the default in one of the major distros
Ok
I can confirm similar behaviour on openSuse tumbleweed. I just had to update approx 23 flatpaks and had to enter a password far too many times, it also failed after each one and had to re-start the update several times. While the password prompt was up, it was failing other packages in the background.
Created attachment 160504 [details] Discover error during flatpak update
Same here, also opensuse Tumbleweed. This is a long standing issue and quite annoying TBH
A possibly relevant merge request was started @ https://invent.kde.org/plasma/discover/-/merge_requests/850
Git commit 90f329899d67924c5c3c392a528c87251cd1b7c9 by Harald Sitter. Committed on 30/08/2024 at 05:36. Pushed by sitter into branch 'master'. flatpak: merge transactions into a single transaction with multiple operations this change is comprised of two parts: This is a new object that seeks to merge multiple discover transactions into a single flatpak transaction (with multiple operations as part of it). The way this works is that instead of starting FlatpakJobTransactions right away we schedule them in the merger. The merger will then dispatch all transactions that have been made in a single eventloop run into one backing transaction. The threading code has been largely redone to deal with it being comprised of multiple operations on the backing side. The most interesting bit of code here is inside setCurrentRef and handles the transition from one ref to another. FlatpakTransactionThread holds a reference to all associated FlatpakJobTransaction and on-demand connnects/disconnects signals as necessary when the flatpak-side refs change. i.e. to the UI code it seems as though each FlatpakJobTransaction stands on its own because we direct signal emission accordingly. Talking about signals: to simplify locking concerns all interaction between the Thread and its current Transaction is done through signals. This goes so far that the current Transaction is only held as a void* such that one doesn't accidentally call it directly. M +111 -53 libdiscover/backends/FlatpakBackend/FlatpakJobTransaction.cpp M +6 -9 libdiscover/backends/FlatpakBackend/FlatpakJobTransaction.h M +195 -92 libdiscover/backends/FlatpakBackend/FlatpakTransactionThread.cpp M +52 -18 libdiscover/backends/FlatpakBackend/FlatpakTransactionThread.h https://invent.kde.org/plasma/discover/-/commit/90f329899d67924c5c3c392a528c87251cd1b7c9