Right, so you’ve graduated from the stone tools of rpm and the venerable-but-aging yum. Welcome to dnf, the modern package manager. It stands for ‘Dandified Yum’, which is both the best and worst name in open source. It’s essentially yum but with a better dependency resolver, better performance, and a much saner API. It’s what you should be using on any modern Fedora, RHEL, or CentOS system. Let’s get you up to speed.

The first thing to know is that dnf is mostly command-line compatible with yum. If you’ve used yum install foo, dnf install foo will work exactly as you’d expect. This is by design, to make the transition painless. But under the hood, it’s a whole different, much more competent beast.

Installing and Removing: The Basics

Installing a package is straightforward. You ask, and if it exists in your configured repositories, dnf figures out all the dependencies and makes it happen.

sudo dnf install htop

This will show you the list of packages it’s about to install (the package itself plus any dependencies) and ask for confirmation. This is your last chance to bail. Now, removing is its inverse:

sudo dnf remove htop

Here’s the first ‘gotcha’. Removing a package does not, by default, remove the dependencies that were pulled in with it. Those orphans just sit there on your system, useless and forgotten. This is how systems accumulate cruft. To clean them up, you need:

sudo dnf autoremove

This will find and remove any leaf packages that were installed as a dependency and are no longer needed by any other package. Get in the habit of running this after an uninstall.

The Art of the Update

Updating your system is a critical operation, and dnf gives you a few ways to do it.

sudo dnf update

This updates every single package on the system to the latest available version in your repositories. It’s the standard “do all the updates” command. But sometimes you only care about one specific package, maybe because a new version fixes a bug you’re hitting.

sudo dnf update httpd

This updates only the httpd package and any of its dependencies that must change as a result. It’s precise and surgical.

Now, for the love of all that is holy, always read the update summary before hitting ‘y’. Sometimes an update will remove a package due to some dependency resolution weirdness or obsoletion. dnf will tell you this explicitly in the transaction summary. Blindly mashing ‘y’ here can lead to a very bad day.

Finding What You Need: search and info

You don’t always know the exact name of the package you need. This is where search becomes your best friend.

dnf search "video converter"

This scours package names, summaries, and descriptions for your search term. The output can be verbose, but it’s comprehensive. For a more precise search only on the package name, use dnf list --name-only <pattern>.

Once you find a promising candidate, say ffmpeg, you need to investigate it. This is what info is for.

dnf info ffmpeg

This is arguably one of the most useful commands. It doesn’t require sudo and it gives you the gold: the version in the repos, the release size, the official description, and, crucially, the URL for the project’s homepage. Before you install anything, run dnf info on it. It answers the question, “What exactly am I about to install?”

Why This All Matters: Repositories and RPMs

Here’s the key insight: dnf doesn’t magically know about every piece of software. It knows about the repositories (/etc/yum.repos.d/) you’ve told it about. It builds a local cache of metadata (the dnf makecache command) from those repos. Every search, info, install, and update operation works by querying this local cache. This is why it’s so fast compared to the older yum.

When you run dnf install, it calculates the complete transaction—dependencies, updates, obsoletes—and then downloads the required RPM files. It then uses the rpm command itself (behind the scenes) to actually install them, handing off the meticulously resolved plan for execution. It’s the brilliant strategist, and rpm is the grunt following orders. This separation is why you should almost never use rpm by hand for installs; you’d be cutting the general out of the loop and sending the privates in without a plan.