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.
Yes, Silverblue is immutable and comes with Podman and Toolbox to create OS containers. Podman is an OS container technology similar to Docker. Toolbox is the default framework that uses Podman to create OS containers. But many prefer to install Distrobox because it’s easier to use than Toolbox. Each Distrobox provides a terminal environment for the user’s choice of a mutable distro. The container’s distro may be various flavors of Debian, Ubuntu, Arch, Fedora, RHEL, openSUSE, Solus, Pop!_OS, etc. There is no container limit. So, for example, if you want to run several .deb packages, you might create a Distrobox based on Debian and install the .deb packages with its APT command. Same with .rpm and DNF. So, it’s quite normal for anyone with Silverblue to not only run Flatpaks and AppImages but to also easily run virtually any other Linux software. A Distrobox command can also “export” installed applications to the atomic host environment so that all the user has to do is click any app’s application menu icon to launch it. So, .deb apps, .rpm apps, flatpaks, etc. all run seamlessly side-by-side. Anyone with mutable distro experience knows 90% of what it takes to run Silverblue.
The main change in this release is that DNF UI now uses DNF5’s dnf5daemon for transaction preview and apply, instead of its own custom transaction service. This removes a lot of application-specific privileged code and should make the app much easier to maintain.
The previous extra transaction resolve before apply has also been removed. If the package state changes after the preview is prepared, the transaction now fails with a clearer message and asks the user to prepare the preview again.
DNF UI now depends on dnf5daemon-server and can be packaged as a single binary application.
Users who want different authorization behavior can use the standard dnf5daemon polkit packages, such as dnf5daemon-server-polkit, instead of DNF UI carrying its own privileged service policy.
If you upgrade from 0.1.7 to 0.2.0 from inside DNF UI, please close and reopen the app after the transaction finishes. The new release removes the old custom transaction service, so the already-running 0.1.7 process should not be kept open after the upgrade.
Thanks for all the responses, feedback, and testing so far. It has already been very helpful.
I am now working on the 0.3.x series of DNF UI, which includes fixes for many of the issues reported here and on GitHub.
More testing is very welcome. Real-world feedback is the best way to find issues, improve the user experience, and make the application more reliable across different Fedora systems and desktop environments.
If you try the latest version, please report anything that seems broken, confusing, slow, unexpected, or especially useful.
Thanks again to everyone who has tested DNF UI so far.
