Product SiteDocumentation Site

Chapter 6. DNF

6.1. Checking For and Updating Packages
6.1.1. Checking For Updates
6.1.2. Updating Packages
6.1.3. Preserving Configuration File Changes
6.2. Packages and Package Groups
6.2.1. Searching Packages
6.2.2. Listing Packages
6.2.3. Displaying Package Information
6.2.4. Installing Packages
6.2.5. Removing Packages
6.2.6. Working with Transaction History
6.3. Configuring DNF and DNF Repositories
6.3.1. Setting [main] Options
6.3.2. Setting [repository] Options
6.3.3. Using DNF Variables
6.4. Viewing the Current Configuration
6.5. Adding, Enabling, and Disabling a DNF Repository
6.6. Additional Resources
DNF is the The Fedora Project package manager that is able to query for information about packages, fetch packages from repositories, install and uninstall packages using automatic dependency resolution, and update an entire system to the latest available packages. DNF performs automatic dependency resolution on packages you are updating, installing or removing, and thus is able to automatically determine, fetch and install all available dependent packages. DNF can be configured with new, additional repositories, or package sources, and also provides many plug-ins which enhance and extend its capabilities. DNF is able to perform many of the same tasks that RPM can; additionally, many of the command line options are similar. DNF enables easy and simple package management on a single machine or on groups of them.

Secure package management with GPG-signed packages

DNF provides secure package management by enabling GPG (Gnu Privacy Guard; also known as GnuPG) signature verification on GPG-signed packages to be turned on for all package repositories (package sources), or for individual repositories. When signature verification is enabled, DNF will refuse to install any packages not GPG-signed with the correct key for that repository. This means that you can trust that the RPM packages you download and install on your system are from a trusted source, such as The Fedora Project, and were not modified during transfer. See Section 6.3, “Configuring DNF and DNF Repositories” for details on enabling signature-checking with DNF, or Section A.3.2, “Checking Package Signatures” for information on working with and verifying GPG-signed RPM packages in general.
DNF also enables you to easily set up your own repositories of RPM packages for download and installation on other machines.
Learning DNF is a worthwhile investment because it is often the fastest way to perform system administration tasks, and it provides capabilities beyond those provided by the PackageKit graphical package management tools.

DNF and superuser privileges

You must have superuser privileges in order to use the dnf command to install, update or remove packages on your system. All examples in this chapter assume that you have already obtained superuser privileges by using either the su or sudo command.

6.1. Checking For and Updating Packages

6.1.1. Checking For Updates

The quickest way to check for updates is to attempt to install any available updates by using the dnf upgrade command as follows:
~]# dnf upgrade
Last metadata expiration check performed 1:24:32 ago on Thu May 14 23:23:51 2015.
Dependencies resolved.
Nothing to do.
Complete!
Note that dnf upgrade installs only those updates that can be installed. If a package cannot be updated, because of dependency problems for example, it is skipped.
The dnf check-update command can be used see which installed packages on your system have new versions available, however it does not mean that they can be successfully installed. This command is therefore mostly useful in scripts and for checking for updated packages that were not installed after running dnf upgrade.
For example:
~]# dnf check-update
Using metadata from Mon Apr 20 16:34:10 2015 (2:42:10 hours old)

python.x86_64                     2.7.9-6.fc22          updates
python-cryptography.x86_64        0.8.2-1.fc22          updates
python-libs.x86_64                2.7.9-6.fc22          updates
The packages in the above output are listed as having updated versions. The line in the example output tells us:
  • python — the name of the package,
  • x86_64 — the CPU architecture the package was built for,
  • 2.7.9 — the version of the updated package,
  • 6.fc22 — the release of the updated package,
  • updates-testing — the repository in which the updated package is located.

6.1.2. Updating Packages

You can choose to update a single package, multiple packages, or all packages at once. If any dependencies of the package, or packages, you update have updates available themselves, then they are updated too.

Updating a Single Package

To update a single package, run the following command as root:
dnf upgrade package_name
For example, to update the python package, type:
~]# dnf upgrade python
Using metadata from Mon Apr 20 16:38:16 2015 (2:42:14 hours old)
Dependencies resolved.
==================================================================
 Package       Arch       Version       Repository       Size
==================================================================
Upgrading:
 python        x86_64     2.7.9-6.fc22  updates           92 k
 python-libs   x86_64     2.7.9-6.fc22  updates          5.8 M

Transaction Summary
==================================================================
Upgrade  2 Packages

Total download size: 5.9 M
Is this ok [y/N]:
This output contains:
  1. python.x86_64 — you can download and install new python package.
  2. python-libs.x86_64 — DNF has resolved that the python-libs-2.7.9-6.fc22.x86_64 package is a required dependency of the python package.
  3. DNF presents the update information and then prompts you as to whether you want it to perform the update; DNF runs interactively by default. If you already know which transactions DNF plans to perform, you can use the -y option to automatically answer yes to any questions DNF may ask (in which case it runs non-interactively). However, you should always examine which changes DNF plans to make to the system so that you can easily troubleshoot any problems that might arise.
    If a transaction does go awry, you can view DNF's transaction history by using the dnf history command as described in Section 6.2.6, “Working with Transaction History”.

Updating and installing kernels with DNF

DNF always installs a new kernel in the same sense that RPM installs a new kernel when you use the command rpm -i kernel. Therefore, you do not need to worry about the distinction between installing and upgrading a kernel package when you use the dnf command: it will do the right thing, regardless of whether you are using the dnf upgrade or dnf install command.
When using RPM, on the other hand, it is important to use the rpm -i kernel command (which installs a new kernel) instead of rpm -u kernel (which replaces the current kernel). See Section A.2.1, “Installing and Upgrading Packages” for more information on installing and updating kernels with RPM.

Updating All Packages and Their Dependencies

To update all packages and their dependencies, enter dnf upgrade without any arguments:
dnf upgrade

6.1.3. Preserving Configuration File Changes

You will inevitably make changes to the configuration files installed by packages as you use your Fedora system. RPM, which DNF uses to perform changes to the system, provides a mechanism for ensuring their integrity. See Section A.2.1, “Installing and Upgrading Packages” for details on how to manage changes to configuration files across package upgrades.