Like many of you, I spend a lot of time managing packages on Fedora. While dnf repoquery and standard RPM CLI commands are great, navigating deeply nested dependencies or quickly figuring out reverse dependencies (“what will break if I remove this package?”) can sometimes be tedious in a terminal.
To make this easier, I’ve been working on an open-source graphical tool called Dendro. It’s written in Python & PyQt6 and focuses on dependency visualization and package inspection.
(Alternatively, standalone AppImages and source code are available on the repository).
Looking for your feedback:
This is an early release and I’d really appreciate input from the Fedora community:
Packaging & Spec: If you’re an experienced RPM packager, I’d love feedback on the .spec file and package structure.
DNF5 Integration: Current integration works with standard DNF/RPM bindings; I’d love suggestions on making it feel even more native with the DNF5 transition.
General UI/UX: Any features or workflows that would make package inspection smoother for you.
Fair question! For me it mostly came down to a few daily annoyances I had with the CLI tools:
Safe cleanups: Whenever I want to remove an old library or unused package, I’m always paranoid that dnf remove will silently try to pull half my desktop environment with it. In Dendro I can just click the package, see the reverse dependencies immediately, and get a warning if anything critical like systemd or glibc would be touched.
Tracing dependency bloat: dnf repoquery --tree is great, but when a package pulls in hundreds of megabytes of dependencies, reading that huge wall of text in the terminal gets tiring fast. A collapsible GUI tree makes it much easier to see which exact branch is responsible for pulling in what.
Quick inspection: Browsing files installed by an RPM or checking recent DNF history/rollback without having to remember long rpm/dnf command flags every time.
Basically, tools like GNOME Software only focus on flatpaks and high-level apps, while raw terminal queries can be tedious for deep inspection. Dendro is just meant to sit in the middle as a handy visual tool for Fedora users who want to see what’s actually happening under the hood.
From a quick look at the code, it doesn’t currently seem to be binding to an API, but rather executing commands and parsing the text output, which is oriented to human reading.
Right now, it’s mostly executing CLI commands under the hood and parsing the text output. Doing it that way was just the quickest path for me to get a working prototype off the ground and iterate on the UI/UX. But I’m well aware that scraping CLI text is brittle and locale-dependent.
What I’d ideally like to transition to:
Using the native librpm Python bindings (import rpm) to query the local RPM database directly for headers, files, and capabilities without shelling out.
Migrating to the official libdnf5 Python bindings for repo queries and transaction handling.
I haven’t had the chance to dive deeply into the libdnf5 Python API yet, as getting the prototype working was my main focus. If you have any recommendations, documentation pointers, or example projects doing this cleanly, I’d genuinely appreciate the guidance!
First of all, I don’t think you should be using the introductions tag for this, it produces unnecessary noise when there are better suited tags available. That said, what does “Queue Removal” do exactly? Is it a dependency explorer or does it also allow management? Since dnf5 doesn’t have `dnf repoquery --tree` yet, this could be a useful implementation as well.
Thanks for the heads up on the tag! I tried to remove introductions, but as a new user on the forum, it looks like my edit window has already locked for the topic. If a moderator happens to come across this, please feel free to drop the tag!
Regarding “Queue Removal”: Dendro is intended to be both an explorer and a package manager. The queue acts as a safe staging area:
You can stage multiple packages for installation or removal in batch rather than modifying the system one-by-one.
Once queued, it triggers a pre-flight dry run to preview the collective dependency changes and specifically checks if core system packages (like kernel, systemd, or glibc) are scheduled for removal by accident.
If everything looks good, confirming the queue executes the transaction via Polkit (pkexec dnf5 or dnf) with live output in the drawer.
And you made a great point about dnf5 lacking --tree! Missing that interactive tree visualization during everyday package inspection was honestly one of the main motivations that drove me to build this. Really glad to hear it helps fill that gap!
(P.S. I also just tagged v1.3.0 on GitHub with some fresh improvements if you happen to test it out!)
Just wanted to share a quick update: I’ve just tagged and released v1.4.0 with several improvements to package categorization, inspector details, and container support.
Key Highlights in v1.4.0:
Smarter Package Categorization: Instead of relying on static name patterns, Dendro now inspects actual package file footprints:
CLI Disambiguation: Packages like yt-dlp, ripgrep, ansible-core, and bat are now properly recognized as Command-Line Tools while retaining their language runtime tags, rather than being dumped into generic library buckets.
Firmware Guard: Applications like gnome-firmware are verified via their GUI launchers so they don’t get mislabeled as hardware microcode.
Classification Insights in Inspector: The Package Inspector panel now displays the specific rationale behind each classification (e.g., detection of user command binaries, Section 1 manual pages, or desktop entries).
If you’re using the COPR repository, you can update with:
You’re completely right, good catch! I had overlooked the /usr/bin and /usr/sbin unification that landed in Fedora 40.
The intention was to separate background daemons and admin utilities from standard user commands, but as you pointed out, relying on the /usr/sbin path is definitely becoming obsolete on modern Fedora.
Fortunately, the classifier also checks for:
Systemd service units (/usr/lib/systemd/system/*.service)
Manual page sections: specifically Section 8 (man8, reserved for system administration commands) versus Section 1 (man1, for general user commands).
Thanks a lot for pointing this out! I’ll update the heuristic logic to deprioritize checking the /usr/sbin path and rely more strictly on systemd units and man8 documentation instead.
Good call on /usr/libexec. I actually just pushed v1.4.1 to address both this and the /usr/sbin symlink merge.
Instead of relying on path splits between bin and sbin, the app now treats them uniformly and specifically checks /usr/libexec to catch internal helpers and background services (like polkitd or D-Bus backends) so they don’t clutter the user CLI tools list. I also paired that with checks for systemd unit files and man8 vs man1 sections to separate daemons from actual interactive commands.
Appreciate the pointer, it definitely helped make the classification logic a lot cleaner on modern Fedora.
A light theme is definitely on my to-do list. Right now it’s hardcoded to dark, but I’m planning to add a light palette / toggle to follow the system theme in an upcoming update.
As for the icon: there should actually already be an app icon bundled with it! Is it not showing up in your desktop launcher? How did you install it (COPR, AppImage, or from source)? Or did you mean icons inside the app interface itself?
I installed dendro from your copr, and I’ve found an icon at /usr/share/icons/hicolor/256x256/apps/io.github.xyasharx.Dendro.png. However it doesn’t show in the KDE Kickoff launcher, and when I try to view it with Gwenview this is the result:
Ah, good catch! That error from Gwenview means the .png file itself is corrupted or got exported incorrectly (likely an empty file or broken image header). No wonder KDE Kickoff couldn’t render it.
I’ll re-export clean PNGs from the master SVG and also install the scalable SVG directly into /usr/share/icons/hicolor/scalable/apps/ (which KDE handles much better anyway).
Pushing a quick update to COPR in a bit to fix this. Really appreciate you digging into the file path and finding the exact issue!
Release Notes: 
