Help test DNF UI 🧪

[ErikMN]

Hi everyone!

I’m looking for help testing DNF UI so we can make it as good, reliable, and pleasant to use as possible.

DNF UI is still a young project, and real-world testing is extremely valuable. Different Fedora systems have different repositories, package sets, hardware, network conditions, desktop environments, and update situations. That means feedback from other users can catch issues I would never see on my own machine.

What I need help testing 🔍

I would especially appreciate testing around:

• Searching for packages
• Listing installed packages
• Listing available packages
• Listing upgradable packages
• Refreshing repositories
• Previewing transactions before applying them
• Installing, removing, reinstalling, and upgrading packages
• Upgrade All
• Repository signing key prompts
• Package details, changelogs, dependencies, and file lists
• Column visibility and table behavior
• Cancellation / Stop buttons during long operations
• Error handling when repositories are unavailable or metadata is stale

What kind of feedback is useful? 📝

Any feedback is welcome, but the most helpful reports include:

• What you were trying to do
• What you expected to happen
• What actually happened
• Your Fedora version
• Your desktop environment
• Whether you installed from a package, built from source, or ran from the repo
• Screenshots, terminal output, or logs if available

Bug reports are very welcome, but so are smaller comments like:

• “This wording is confusing”
• “This button did not do what I expected”
• “This took longer than I expected”
• “The app handled this situation well”
• “This part of the UI feels awkward”

Safety note ⚠️

DNF UI can perform real package operations through dnf5daemon, so please test carefully.

If you want to help without changing your main system, testing in a virtual machine is a great option. Even just testing search, package listing, repository refresh, and transaction preview is useful.

Goal 🎯

The goal is to make DNF UI stable, understandable, and trustworthy before calling it mature.

If you try the app and notice anything strange, confusing, broken, slow, or surprisingly good, please leave a comment here or open a separate issue.

Thanks for helping make DNF UI better!

[adrianinsaval]

When listing installed packages the repo field just shows @System it would be useful to see what repo these packages where installed from or if that's not possible at least what repo they are available on for reference.

In the dependencies tab it would be useful if you could show what packages can provide the listed requirements as clickable hyperlinks, it would also be nice if the packages list in "Require By" were clickable hyperlinks

[ErikMN]

When listing installed packages the repo field just shows @System it would be useful to see what repo these packages where installed from or if that's not possible at least what repo they are available on for reference.

Thanks, this is a good suggestion.

I looked into this, and dnf-ui can now show the installed package origin in the package Info panel as "Installed From".

There is one limitation: the installed RPM database does not always preserve a clean original repository name.
Depending on how the package was installed, libdnf5 may report values such as "updates", "commandline", or "unknown".
Because of that, I do not want to replace the main table Repo column with this value, since it could make the package list more confusing.

So the current plan is:

• keep the table Repo column behavior unchanged
• show the raw installed-origin value in the Info panel
• avoid guessing or hiding what libdnf5 reports

This gives users access to the information when it exists, without pretending that the system always knows the original repository perfectly.

In the dependencies tab it would be useful if you could show what packages can provide the listed requirements as clickable hyperlinks, it would also be nice if the packages list in "Require By" were clickable hyperlinks

Thanks, this is a useful suggestion, especially for the "Required By" list where the entries already point to concrete packages.

I did some investigation and a small prototype.
Making Required By entries clickable is possible, but it touches more of the details UI than I want to merge right now.
The Dependencies tab is currently a simple plain-text view, and adding clickable package links means adding structured dependency output, link tracking, click handling, and exact package navigation from inside the text view.

For "Requires" it is even more involved, because those entries are often capabilities rather than package names.
A single requirement can be provided by multiple packages, or by virtual provides, so we would need a proper provider lookup and a clear UI for choosing between providers.

So I am not rejecting the idea. I am postponing it until it can be designed cleanly without adding too much complexity to the current details panel.