I am not trying to dismiss or replace existing work.
My goal with dnf-ui is a fast native GTK4 interface targeting DNF5, with transactions handled through a privileged system service using Polkit.
dnfdragora is definitely relevant existing work, but dnf-ui has a somewhat different design and UI direction. I would also be interested in feedback from people who have used dnfdragora, especially about what workflows they think should be improved.
It does call libdnf5 Base::load_config() and creates repositories from the system configuration,
so /etc/dnf/dnf.conf and the normal system repository configuration should be honored.
It may still feel a bit slower than command-line dnf because DNF UI performs a separate preview step, rebuilds package state before preview and apply, and resolves the transaction again before applying it to verify that the approved preview still matches current package state.
However I have not touched the dnf configuration much on my devices so this needs to be investigated further. I have been running queries and transaction at almost native CLI speed.
Does the libdnf5 allow you to do the preview and then wait for the UI confirm in one transaction? I’d assume it can as that is what the dnf5 CLI tool does.
Doing 2 transactions and checking they match hopefully could be avoided.
Doing the --refresh is what I almost always do.
But some users may want it to be optional so things are faster.
To clarify, DNF UI does not currently run two RPM transactions.
It resolves the transaction once to build the preview, then after the user confirms it resolves the same request again and compares the result with the preview that was approved.
Only then does it run the actual transaction.
That was a conservative safety choice so the app would not apply something different from what was shown in the preview if package state changed in between.
But I agree that this is probably avoidable.
A better design may be to keep the resolved transaction or transaction session alive between preview and Apply, similar to how an interactive CLI flow works.
That should avoid duplicate resolver and repo setup work.
This would not make the system immutable between preview and Apply.
If another package transaction happens on the side before the user presses Apply, DNF UI should fail the prepared transaction, discard the preview, and ask the user to refresh and review again.
The goal is that Apply never silently means something different from the preview the user accepted.
I am also investigating replacing DNF UI’s custom privileged transaction service with dnf5daemon for this part. The app would still use libdnf5 locally for listing, search, details, etc., but transaction preview and apply would go through dnf5daemon.
That would give the same model: resolve, show preview, then apply the same resolved transaction and let Polkit prompt on Apply.
The user can always do a manual repo refresh by clicking that button.
So the question is mostly if this extra resolve check is worth the extra latency overhead.
I will have to investigate this.
You would need to check, but doesn’t DNF hold a lock to prevent two transactions racing against each other? If that lock is in DNF then you have immutable semantics.
Edit: I did the obvious test
Session 1: sudo dnf update - leave at the confirm prompt
Session 2: sudo dnf update
$ dnf update
Waiting for a lock on the system repository. The following processes are currently accessing it:
4101 dnf update
Use the "--skip-file-locks" option to bypass the lock.
That suggests the CLI keeps the DNF lock while waiting at the confirmation prompt. If DNF UI keeps the resolved transaction or dnf5daemon session alive between preview and Apply, then normal DNF transactions should block on that same lock instead of changing the system underneath the preview.
I still need to verify the exact lock lifetime with dnf5daemon, but if it works that way, the extra resolve-and-compare step is probably unnecessary. The UI could show the preview, keep the prepared transaction/session alive, then apply that same transaction after confirmation.
I chose to test DNF-UI on Fedora Silverblue 44. This is just feedback on the experience. Legacy packages don’t install on the Silverblue host. So, I downloaded dnf-ui-0.1.7-1.fc44.x86_64.rpm from github. I used a flatpak callled BoxBuddy to install the downloaded package into a Distrobox container called dnf43, which is based on Fedora 43. I also used BoxBuddy to export the .desktop file that creates the application launcher menu icon. The icon displayed correctly and launched the application correctly. However the icon shown on the GNOME desktop’s topbar was a generic blue diamond. I was able to correct that by changing the StartupWMClass= line in the .desktop file (see image below). I then used DNF-UI to search for “calculator” and marked a listed package for install. The install failed (see image below). I’m familiar with using Synaptic for APT. And DNF-UI appears to be a faithful replication for DNF5. Based on my brief experience with the version of DNF-UI that I tested, I’d say that the application is user-friendly and that the finished package would add value to my personal workflow.
Thank you for testing the app, this is very useful feedback.
The topbar icon issue sounds like a real desktop integration bug. Your StartupWMClass=com.fedora.dnfui change makes sense, and I will fix that in the packaged desktop file.
The transaction failure also makes sense from the screenshot. Version 0.1.7 still uses DNF UI’s own transaction service, and the error Could not connect. No such file or directory means the UI could not reach that service.
In a Distrobox exported desktop app, the service path, D-Bus activation, or permissions may not be available in the same way as on a normal Fedora Workstation install.
DNF UI is currently aimed at regular Fedora systems using DNF5. In Distrobox it manages packages inside the container, not the Silverblue host.
I am currently working on migrating transaction handling to DNF5’s dnf5daemon instead of DNF UI’s own service. That should remove DNF UI’s custom transaction service and make the app simpler and more maintainable. It may also improve behavior in container-style environments because there will be fewer DNF UI-specific service pieces involved, but I do not want to promise Distrobox support until that has been tested properly.
Thanks again for testing it on Silverblue and Distrobox. Even though that is not the main target right now, this kind of testing helps a lot.
