Linux package management with dnf

Learn how to install packages on Linux with the dnf command, then download our cheat sheet to keep the right command at your fingertips.
48 readers like this.

Installing an application on a computer system is pretty simple. You copy files from an archive (like a .zip file) onto the target computer in a place the operating system expects there to be applications. Because many of us are accustomed to having fancy installer "wizards" to help us get software on our computers, the process seems like it should be technically more complex than it is.

What is complex, though, is the issue of what makes up an application. What users think of as a single application actually contains code borrowing from software libraries (i.e., .so files on Linux, .dll files on Windows, and .dylib on macOS) scattered throughout an operating system.

So that users don't have to worry about that veritable matrix of interdependent code, Linux uses a package management system to track what application needs what library, and which library or application has security or feature updates, and what extra data files were installed with each software title. A package manager is, essentially, an installer wizard. They're easy to use, they provide both graphical interfaces and terminal-based interfaces, and they make your life easier. The better you know your distribution's package manager, the easier your life gets.

Installing applications on Linux

If you're a casual desktop user who wants to install an application on Linux, then you may be looking for GNOME Software, a desktop application browser.

Image of the GNOME Software application

It works as you'd expect: You click through its interface until you find an application that seems like it would be useful, and then you click the Install button.

Alternately, you can open .rpm or .flatpakref packages downloaded from the web in GNOME Software for it to install them for you.

If you're inclined toward controlling your computer with typed commands, read on!

Finding software with dnf

Before you can install an application, you may need to confirm that it exists on your distribution's servers. Usually, searching for the common name of an application with dnf suffices. For instance, say you recently read an article about Cockpit and decide you want to try it. You could search for cockpit to verify that your distribution includes it:

$ dnf search cockpit
 Last metadata expiration check: 0:01:46 ago on Tue 18 May 2021 19:18:15 NZST.
 ==== Name Exactly Matched: cockpit ====
 cockpit.x86_64 : Web Console for Linux servers

==== Name & Summary Matched: cockpit ==
 cockpit-bridge.x86_64 : Cockpit bridge server-side component
 cockpit-composer.noarch : Composer GUI for use with Cockpit

There's an exact match. The package listed as a match is called cockpit.x86_64, but the .x86_64 part of the name only denotes the CPU architecture it's compatible with. By default, your system installs packages with matching CPU architectures, so you can ignore that extension. Therefore, you've confirmed that the package you're looking for is indeed called simply cockpit.

Now you can confidently install it with dnf install. This step requires administrative privileges:

$ sudo dnf install cockpit

More often than not, that's the typical dnf workflow: search and install.

Sometimes, however, the results of dnf search aren't clear to you, or you want more information about a package than just its common name. There are a few relevant dnf subcommands, depending on what information you're after.

Package metadata

If you feel like your search got you close to the package you want, but you're just not sure yet, it's often helpful to take a look at the package's metadata, such as the project's URL and description. To get this info, use the pleasantly intuitive dnf info command:

$ dnf info terminator
Available Packages
Name         : terminator
Version      : 1.92
Release      : 2.el8
Architecture : noarch
Size         : 526 k
Source       : terminator-1.92-2.el8.src.rpm
Repository   : epel
Summary      : Store and run multiple GNOME terminals in one window
URL          :
License      : GPLv2
Description  : Multiple GNOME terminals in one window.  This is a project to produce
             : an efficient way of filling a large area of screen space with
             : terminals. This is done by splitting the window into a resizeable
             : grid of terminals. As such, you can  produce a very flexible
             : arrangements of terminals for different tasks.

This info dump tells you the version of the available package, which repository registered with your system provides it, the project's website, and a long description of what it does.

What package provides a file?

Package names don't always match what you're looking for. For instance, suppose you're reading documentation telling you that you must install something called qmake-qt5:

$ dnf search qmake-qt5
No matches found.

The dnf database is extensive, so you don't have to restrict yourself to searches for exact matches. You can use the dnf provides command to learn whether anything provides what you're looking for as part of some larger package:

$ dnf provides qmake-qt5
qt5-qtbase-devel-5.12.5-8.el8.i686 : Development files for qt5-qtbase
Repo        : appstream
Matched from:
Filename    : /usr/bin/qmake-qt5

qt5-qtbase-devel-5.15.2-3.el8.x86_64 : Development files for qt5-qtbase
Repo        : appstream
Matched from:
Filename    : /usr/bin/qmake-qt5

This confirms that the application qmake-qt5 is a part of a package named qt5-qtbase-devel. It also tells you that the application gets installed to /usr/bin, so you know exactly where to find it once it's installed.

What files are included in a package?

There are times when I find myself approaching dnf from a different angle entirely. Sometimes, I've already confirmed that an application is installed on my system; I just can't figure out how I got it. Other times, I know I have a specific package installed, but I'm not clear on exactly what that package put on my system.

If you ever need to "reverse engineer" a package's payload, you can use the dnf repoquery command along with the --list option. This looks at the repository's metadata about a package and returns a list of all files provided by that package:

$ dnf repoquery --list qt5-qtbase-devel

These lists can get long, so it helps to pipe the command through less or your favorite pager.

Removing an application

Should you decide you no longer need an application installed on your system, you can use dnf remove to uninstall it, all of the files that were installed as part of its package, and any dependencies that are no longer necessary:

$ dnf remove bigapp

Sometimes, dependencies get installed with one app and are later found useful by some other application you install. In the event that two packages require the same dependency, dnf remove does not remove the dependency. It's not unheard of to end up with a stray package here and there after installing and uninstalling lots of applications. About once a year, I perform a dnf autoremove to clear out any unused packages:

$ dnf autoremove

This isn't necessary, but it's a housecleaning step that makes me feel better about my computer.

Getting to know dnf

The more you know about how your package manager works, the easier it is for you to install and query applications when necessary. Even if you're not a regular dnf user, it can be useful to know it when you find yourself interfacing with an RPM-based distro.

Having graduated from yum, one of my favorite package managers is the dnf command. While I don't love all its subcommands, I find it to be one of the more robust package management systems out there. Download our dnf cheat sheet to get used to the command, and don't be afraid to try some new tricks with it. Once you get familiar with it, you might find it hard to use anything else.

What to read next
Seth Kenlon
Seth Kenlon is a UNIX geek, free culture advocate, independent multimedia artist, and D&D nerd. He has worked in the film and computing industry, often at the same time.


Working with dnf groups is trickier than it seems. I prefer to use
dnf grouplist
to show installed and available groups. The trickiness comes with you try to install one of them. For example, say you want to install
Development Tools
The syntax is
dnf group install "Development Tools"
which is simpler than trying to do
dnf install @development-tools
Is this right? Or is it
dnf install @DevelopmentTools
or something else?
The man page is a bit sketchy on this.

I do a grouplist with the -v flag, which lists the exact group nickname in parentheses.

$ dnf grouplist -v
RPM Development Tools (rpm-development-tools)
Development Tools (development)
Graphical Administration Tools (graphical-admin-tools)
$ sudo dnf install @development

There may be other ways to do it, but that's what I've done for years-n-years and it hasn't let me down so far.

In reply to by Greg P

dnf is powerful command to simply the tasks ?

There are three programs in play: rpm, yum, and dnf. why are 3 needed ?

I don't understand the question, because 3 commands are not needed. I believe this article demonstrates that effectively.

The 3 commands you list do, however, exist. I can provide some context:

* Yum is historical, and has been refactored to be based on libdnf. It's now an optional interface to dnf for people who have enjoyed Yum over the years and don't want to migrate away from it. It wouldn't surprise me if it eventually is deprecated or symlinked to the `dnf` executable.

* The `rpm` command is a direct interface to the RPM database tracking packages on the system. It exists because Linux provides the user with lots of tools, and it would be a pity to put a database on a user's system with no way to communicate with it. Generally you shouldn't expect to use the `rpm` command, because dnf is a friendlier, unified, and robust way to interact with the RPM system.

In reply to by paul

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.