DNF4 Package Management on RPM Systems

Why DNF4 Exists and Which Systems It Targets

DNF4, also called Dandified YUM 4, is a command-line package manager for RPM-based Linux systems. Its stated purpose is package management, including metadata handling, package downloads and repository operations. The repository describes it as the fourth iteration of a major YUM version and identifies RPM as the package format it manages. This places DNF4 in a specific compatibility category: it is intended for RPM distributions that still ship or require the DNF4 implementation, rather than as a distribution-neutral installer for arbitrary software archives.

The documentation names Fedora 18 and later, including Rawhide, as distributions where DNF4 and its dependencies are available. On other RPM-based distributions, the documented path is to build all required components from their sources. That distinction matters because the repository does not present DNF4 as a portable single-file program. Its build depends on RPM, libsolv, hawkey, librepo, libcomps, CMake and Python.

There is also a more immediate adoption boundary. The opening notice says this repository is for DNF4 only and points users to the separate `rpm-software-management/dnf5` repository for the current DNF version. Consequently, searching for DNF documentation can lead engineers to code that is already outside the current product line. Teams standardizing a new system should first determine whether they need DNF4 compatibility or the separate DNF5 project.

DNF4's Library Stack and Request Flow

DNF4 separates package-management logic into several native libraries rather than implementing every repository and dependency operation inside the Python command layer. The README states that package management uses RPM, libsolv and hawkey. It assigns metadata handling and package downloads to librepo, while libcomps processes component data. The Python repository therefore represents the user-facing and command implementation around an established RPM dependency and repository stack.

The documented division gives engineers a useful model for diagnosing where a problem belongs. RPM identifies the package format, while hawkey and libsolv participate in dependency-aware package selection. librepo is responsible for repository metadata and downloads, and libcomps handles component information. A repository configuration problem, for example, is associated in the documentation with librepo rather than with Python command syntax. That does not prove which component will fail in every case, but it does identify the interfaces the project expects.

The source tree supports this layered model. Directories such as `dnf/`, `etc/`, `scripts/`, `doc/` and `tests/` accompany the top-level `CMakeLists.txt`, `dnf.spec` and `VERSION.cmake`. The README also states that the installed package contains `dnf(8)` and `dnf.conf(8)` manpages, while the online documentation includes API documentation. System administrators therefore have both command reference material and configuration reference material, although the repository overview does not reproduce their settings or enumerate every API.

Installing the DNF4 Package on Fedora

On Fedora 18 and later, the README treats DNF4 as an available package. The documented installation command uses `yum` as the package installation frontend and installs the package named `dnf4`:

sudo yum install dnf4

After a successful package installation, the system should contain the packaged DNF4 command, configuration documentation and manpages. The README does not provide a separate post-install verification command, so it would be inappropriate to invent one here. The installed command reference is `dnf(8)`, and the configuration reference is `dnf.conf(8)`.

The README also documents an optional COPR repository for nightly builds. This is intended to provide DNF nightly builds for the last two stable Fedora versions. If an engineer deliberately chooses those builds, the documented enablement command is:

dnf copr enable rpmsoftwaremanagement/dnf-nightly

After enabling that repository, the installation command remains the one shown above. The documentation does not explain rollback, pinning, update testing or how to remove the nightly repository, so those operational procedures are not established by this repository overview. A production administrator would need distribution packaging documentation or the relevant `dnf(8)` and `dnf.conf(8)` pages for those details.

Building DNF4 from a Git Checkout

Source builds are required on other RPM-based distributions because the README says all components must be built from their sources. It also requires the commands to be run from the DNF Git checkout directory. First, install the build dependencies declared by the package specification:

sudo dnf builddep dnf.spec

The next documented sequence creates a `build` directory, enters it, configures the project with CMake and compiles it:

mkdir build;
pushd build;
cmake ..; # add '-DPYTHON_DESIRED="3"' option for Python 3 build
make;
popd;

The inline comment is significant. By default, the README explains how to run a Python 2 build. For a Python 3 build, `PYTHON_DESIRED` must be passed to `cmake`. The documentation does not give a separate completed Python 3 configuration command, so the supported choice remains the exact option shown in the comment.

After compilation, the checkout exposes separate launchers for the two Python configurations:

PYTHONPATH=`readlink -f .` bin/dnf-2 <arguments>
PYTHONPATH=`readlink -f .` bin/dnf-3 <arguments>

These commands run the freshly built DNF entry point from the checkout. The README does not define the contents of `<arguments>`, so first use should be grounded in the generated `dnf4.8` manual page rather than assumed flags.

Running DNF4 Tests and Reading Generated Manpages

The repository includes a `tests/` directory and documents a build-tree test target. From the Git checkout, configure and compile with test execution in one command sequence:

mkdir build;
pushd build;
cmake .. && make ARGS="-V" test;
popd;

This is the documented way to run the project's test target. The overview does not list the expected test count, execution time, supported platform matrix or test dependencies beyond the broader source-build requirements. It therefore cannot support claims about pass rates or cross-distribution compatibility.

Manpages are optional during the build. Passing `-DWITH_MAN=0` to CMake enables their generation according to the README. Once built, the files are located under `build/doc` and can be inspected with `man -l`:

man -l build/doc/dnf4.8

These blocks should be run in the corresponding working directories, with the CMake command issued from inside `build`. The command reads the generated command manual page from the build tree. This documentation path is especially relevant for source builders because the overview does not enumerate DNF's command options.

DNF4 Packaging, Licensing and Maintenance Boundaries

The repository identifies `GPL-2.0` as its license. The source tree also contains `COPYING` and `PACKAGE-LICENSING`, which are the relevant files for reviewing the project's stated license terms and package licensing details. The repository overview does not summarize exceptions, bundled-library terms or distribution-specific packaging obligations, so it does not support a legal conclusion beyond recording `GPL-2.0` and directing readers to those files.

The project is not archived. Its last push was on 2026-09-17, which is a recent repository event relative to the release history supplied. The listed versions are 4.24.0 from 2025-10-21, 4.23.0 from 2025-03-07 and 4.22.0 from 2024-11-12. These dates show a sequence of releases, but they should not be read as evidence that DNF4 is the preferred choice for new installations. The README explicitly calls DNF5 the current DNF version and confines this repository to DNF4.

Upgrade planning must therefore include a version-boundary check, not only a package update. Engineers should determine why a host is tied to DNF4, inspect the package version available from its distribution or selected repository, and review the generated command and configuration manuals. The README does not document an in-place migration path from DNF4 to DNF5, rollback procedures or a compatibility matrix.

DNF5 Versus the Separate DNF4 Repository

The real alternative named by the documentation is DNF5, maintained in its own repository. The difference is explicit: this repository covers DNF4, while the README says the current DNF version has its own `rpm-software-management/dnf5` repository. For a deployment that simply says “DNF,” selecting this repository would be the wrong boundary because it does not contain the current DNF implementation.

DNF5's architecture, installation command, feature differences, migration process or compatibility policy are not described here. It would therefore be misleading to describe DNF5 as faster, smaller or redesigned without evidence from that repository. What can be stated is the codebase and release boundary: engineers needing DNF4 should examine this project, while engineers needing the current DNF version should follow the README's link to DNF5.

The choice is particularly relevant to new RPM-based systems and automation built around command behavior. The repository overview confirms that DNF4 ships `dnf(8)` and `dnf.conf(8)`, but it does not establish command compatibility with DNF5. Before replacing or upgrading DNF4 in scripts, host provisioning or image construction, teams should verify the target implementation and validate their exact DNF invocations against that target's documentation.

Editorial conclusion

Adopt this repository for systems that specifically require DNF4 or its documented library stack. Do not select it for a new deployment that needs the current DNF version, because the README identifies DNF5 as a separate project with its own repository. Verify the target distribution package, the required Python build choice and whether the deployment can use the documented RPM and manpage interfaces before upgrading an existing installation.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. README
4. Releases
5. rpm-software-management/dnf on GitHub