DNF: Dandified YUM

In Fedora Linux, the official operating system-level package manager is dnf. This implementation seamlessly deprecates the older yum package manager. While the familiar yum commands are still available, at a lower level these are aliased to dnf. That is, attempting to install an application through yum calls dnf under the hood. For instance,

# yum search python-sphinx
Yum command has been deprecated, redirecting to '/usr/bin/dnf search python-sphinx'.
See 'man dnf' and 'man yum2dnf' for more information.
To transfer transaction metadata from yum to DNF, run:
'dnf install python-dnf-plugins-extras-migrate && dnf-2 migrate'

Last metadata expiration check performed 0:04:13 ago on Fri Feb 26 10:16:57 2016.
=========================== N/S Matched: python-sphinx ============================
python-sphinx.noarch : Python documentation generator

Finding Packages

In order to install software on your system through DNF, you first need to find the relevant package names. On the one hand, you might go online and search for the project website and there look for instructions on how to install the given application in Fedora. But, this resource requires the developer to maintain up to date information on these procedures and, in all likelihood, also for every other Linux distribution that they support. On the other hand, you can find the relevant package by performing a search through DNF itself.

dnf [options] search [all] <keywords>...

For instance, you have a Fedora server that hosts a documentation website for your product and you manage the docs using the documentation generator Sphinx. You would like to know what Sphinx contributor modules are available through DNF. From the initial installation you know that the Sphinx package is called python-sphinx and that the contributor modules follow the pattern python-sphinxcontrib-%.

# dnf search python-sphinxcontrib
Last metadata expiration check performed 1:29:47 ago on Wed Mar  2 02:06:05 2016.
====================== N/S Matched: python-sphinxcontrib ======================
python-sphinxcontrib-napoleon.noarch     : Sphinx napoleon extension
python-sphinxcontrib-adadomain.noarch    : Ada domain for the Sphinx
                                         : documentation generator
python-sphinxcontrib-cheeseshop.noarch   : Sphinx extension cheeseshop
python-sphinxcontrib-httpdomain.noarch   : Sphinx domain for documenting HTTP APIs
python-sphinxcontrib-fulltoc-doc.noarch  : Include a full table of contents in
                                         : your Sphinx HTML sidebar
python-sphinxcontrib-issuetracker.noarch : Sphinx integration with different
                                         : issue trackers

From this, you’ve identified fulltoc-doc extension as something you would like to install for your website. By running the installation command with this package name, you can make it available in your Sphinx builds.

In the event that you run a search that finds nothing, the command returns an error code.

# dnf search neovim
Last metadata expiration check performed 2:15:00 ago on Wed Mar  2 02:06:05 2016.
Error: No matches found.

When this happens, DNF searched its database and found no matches to your keyword. This can mean your keyword is wrong or that you misspelled it, the package name and description does not contain the word you’re searching for, or that you need to configure a software repository that makes the package it available to you.

In the case of the example, Neovim is not yet available in the Fedora repositories.

Note

Searching for packages in DNF does not update the metadata. In the event that you are using DNF for the first time or haven’t in a while, you may find it useful to run this command with the --refresh to update metadata before searching.

Searching Metadata

When DNF searches for a keyword, it looks to package names and descriptions by default. For most use cases this is sufficient, but you may occasionally encounter situations where neither the package description nor its name contains the keyword. That’s where the all option comes into play.

For instance, you have enabled a repository to supply the Adobe Flash plugin. You know that a compatibility layer exists for Netscape 4 plugins that you would like to experiment with. The problem is that you do not know the relevant package name offhand. Initially, you attempt to search flash-plugin:

# dnf search flash-plugin
Last metadata expiration check performed 1:47:34 ago on Wed Mar  2 02:06:05 2016.
=========================== N/S Matched: flash-plugin ============================
flash-plugin.x86_64 : Adobe Flash Player 11.2
lpf-flash-plugin.i686 : Adobe Flash Player package bootstrap
lpf-flash-plugin.x86_64 : Adobe Flash Player package bootstrap

Given that this system is configured with an Adobe Flash repository, it returns some results on this search, but not the relevant Netscape 4 plugins that you want to use. What you need to do is search package metadata, in addition to the name and description. You can do so by running the same command as above, but with the all option:

# dnf search all flash-plugin
Last metadata expiration check performed 1:48:52 ago on Wed Mar  2 02:06:05 2016.
============================= Matched: flash-plugin ==============================
flash-plugin.x86_64 : Adobe Flash Player 11.2
lpf-flash-plugin.x86_64 : Adobe Flash Player package bootstrap
lpf-flash-plugin.i686 : Adobe Flash Player package bootstrap
nspluginwrapper.i686 : A compatibility layer for Netscape 4 plugins
nspluginwrapper.x86_64 : A compatibility layer for Netscape 4 plugins

There you are, nspluginwrapper: the package you were looking for. Now that you have the package name, you can install it on your system.

Todo

Readers: The Adobe Flash plugin was chosen as an initial use case for this section. Over the long term, it would be our preference to limit most of our examples to open-source software. We would welcome any suggestions of a better package to use in the example. That is a package that returns a brief list of examples, with the information we want once the user adds the all option.

Installing Packages

Knowing the name of the package you want, you can install the relevant binaries by issuing a command through DNF. When DNF receives the install command, it checks its database to determine which repository contains the package, it then checks to determine what libraries the application needs in order to function.

This is one of the particular advantages package managers provide over the alternative build and installation methods. When you tell DNF to install a package, it installs both that package and all other applications, libraries and utilities that package depends upon. More importantly, moving forward DNF maintains the entire stack, updating both the package you asked it to install and everything that package depends upon.

dnf [options] install <package>...

In the above example of a documentation site built using Sphinx, assume that you would like to install the fulltoc extension. Using this extension provides you with a table of contents in the sidebar that links to the complete project, rather than the typical anchor links to local headings on the page. Since you already know the package name, you can issue the install command to DNF:

# dnf install python-sphinxcontrib-fulltoc
Last metadata expiration check performed 0:00:52 ago on Wed Mar  2 04:28:54 2016.
Dependencies resolved.
================================================================================
Package                       Arch         Version           Repository    Size
================================================================================
Installing:
python-docutils                noarch      0.12-0.3.fc23     fedora        1.5 M
python-pygments                noarch      2.0.2-3.fc23      updates       1.6 M
python-sphinx                  noarch      1.2.3-4.fc23      fedora        1.2 M
python2-sphinxcontrib-fulltoc  noarch      1.1-2.fc23        updates        20 k

Transaction Summary
================================================================================
Install  4 Packages

Total download size: 4.3 M
Installed size: 16 M
Is this ok [y/N]:

Clicking y at this point installs the package on your system, along with the given dependencies. In the even that you know what the dependencies are or don’t care about their being installed, you can run the above command with the -y option, to answer in the affirmative to each prompting—but, this is inadvisable as it means DNF can install a large number of packages without double-checking with you.

Upgrading Packages

Unlike other operating systems, unix-based systems like Fedora Linux do not manage upgrades through push notifications. Instead, when you are ready to perform an upgrade, tell DNF to check in on what is available.

# dnf upgrade

When this command is issued, DNF updates its databases and then checks each installed package against what is available. If it finds that the software repository contains a newer version than what it has installed, it offers to install it for you.

Occasionally, you may only want to upgrade individual packages on your system. For instance, you learn from various resources that a new version of the Linux Kernel is available in the Fedora repositories. Given that kernel updates require a reboot before they are applied to the system, you decide to only upgrade this package before restarting.

# dnf upgrade kernel

Last metadata expiration check performed 0:38:16 ago on Wed Mar  2 04:28:54 2016.
Dependencies resolved.
================================================================================
Package               Arch     Version          Repository                 Size
================================================================================
Installing:
kernel                x86_64     4.4.2-301.fc23      updates               54 k
kernel-core           x86_64     4.4.2-301.fc23      updates               20 M
kernel-modules        x86_64     4.4.2-301.fc23      updates               18 M

Removing:
kernel                x86_64     4.3.3-303.fc23      @updates               0
kernel-core           x86_64     4.3.3-303.fc23      @updates              51 M
kernel-modules        x86_64     4.3.3-303.fc23      @updates              17 M
kernel-modules-extra  x86_64     4.3.3-303.fc23      @updates             2.1 M

Transaction Summary
================================================================================
Install  3 Packages
Remove   4 Packages

Total download size: 39 M
Is this ok [y/N]:

DNF checks in with its database and determines that the updates repository does in fact contain a new version of the Linux Kernel. It prints a report to stdout, informing that it means to install the latest version in the 4.x series, removing its predecessor. It provides the metadata on the number of packages it means to install and remove, the total download size, and it asks if this is okay.

Removing Packages

Eventually, you may find that you have packages installed on your system that you no longer want to use or for some other reason you would like to uninstall them. The same packaging system that tells DNF where install all the binaries, libraries, documentation and source code also tells it how to remove these when the need arises.

dnf [options] remove <package>...

For instance, consider the use case where you spend an afternoon experimenting with various utilities for interfacing with a Git repository. These experiments included several hours testing out GITK, an application that lets you browse the repo through a GUI. After you finish testing, you decide to remove the relevant applications, including GITK.

# dnf remove gitk
Dependencies resolved.
================================================================================
Package    Arch            Version             Repository                 Size
================================================================================
Removing:
gitk       noarch          2.5.0-4.fc23       @updates                    701 k
tcl        x86_64          1:8.6.4-1.fc23     @fedora                     5.1 M
tk         x86_64          1:8.6.4-2.fc23     @fedora                     3.6 M

Transaction Summary
================================================================================
Remove  3 Packages

Installed size: 9.4 M
Is this ok [y/N]:

As you can see from the table, this command registers GITK for removal. It also pegs the tcl and tk packages. Removing GITK renders these packages nonfunctional, so DNF offers to remove them as well.

Removing Dependencies

When you tell DNF to remove a package from your system, it only removes the target package and any packages that depend on that package. It does not removes packages that were installed as dependencies of the target package. That requires that you run a separate autoremove command.

# dnf autoremove
Last metadata expiration check performed 0:09:16 ago on Wed Mar  2 05:08:53 2016.
Dependencies resolved.
================================================================================
Package             Arch    Version        Repository                      Size
================================================================================
Removing:
c-ares-devel        x86_64  1.10.0-5.fc23   @fedora                         84 k
libtxc_dxtn         i686    1:1.0.1-1.fc23  @rpmfusion-free-updates-testing 19 k
libtxc_dxtn         x86_64  1:1.0.1-1.fc23  rpmfusion-free-updates-testing  20 k
libva-intel-driver  i686    1.6.2-1.fc23    @rpmfusion-free-updates-testing 1.8 M
libva-intel-driver  x86_64  1.6.2-1.fc23    @rpmfusion-free-updates-testing 1.7 M

Transaction Summary
================================================================================
Remove  5 Packages

Installed size: 3.6 M
Is this ok [y/N]:

In this case, there are a number of packages that Fedora no longer requires, given that the packages that depend on them have since been uninstalled. When you auto-remove packages, it only removes those that were installed as dependencies and which other installed packages do not depend upon.

< Prev Next >