Community hub
0 subscribers8 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to DNF (software).
Nothing was collected or created yet.
DNF (software)
View on Wikipediafrom Wikipedia
| Dandified Yum | |
|---|---|
 | |
 DNF5 running on Fedora 41 | |
| Developer | Red Hat |
| Initial release | 18 January 2012[1] |
| Stable release | 5.3.0.0[2] 
/ 4 November 2025 |
| Repository | https://github.com/rpm-software-management/dnf,[3] https://github.com/rpm-software-management/dnf5[4] |
| Written in | |
| Operating system | Linux, IBM AIX |
| Platform | RPM |
| Available in | English |
| Type | Package management system |
| License | GPLv2+ & LGPLv2.1+ & New BSD License |
| Website | rpm-software-management |
DNF (abbreviation for Dandified YUM)[7][8][9] is a package manager for Red Hat-based Linux distributions and derivatives. DNF was introduced in Fedora 18 in 2013 as a replacement for yum;[10] it has been the default package manager since Fedora 22 in 2015[11] and Red Hat Enterprise Linux 8 in 2019[12] and is also an alternative package manager for Mageia. DNF performs package management tasks on top of RPM, and supporting libraries.
Usage
[edit]The DNF package manager works similarly to other package managers.[13] Its core usage works very similarly to the Apt Package Manager, such as install, remove, update, and upgrade.[14][13]
Usage for basic command is as follows:[13]
sudo dnf install <package_name>
sudo dnf remove <package_name>
sudo dnf update
sudo dnf upgrade
History
[edit]![[icon]](https://en.wikipedia.org/wiki/File:Wiki_letter_w_cropped.svg){kind=small} | This section needs expansion. You can help by adding to it. (December 2024) |
Perceived deficiencies of yum (which DNF is intended to address) include poor performance, high memory usage, and the slowness of its iterative dependency resolution.[15] DNF uses libsolv, an external dependency resolver.[15]
DNF was originally written in Python, but as of 2016[update], efforts were under way to port it to C and move most functionality from Python code into the new libdnf library[needs update].[16] In 2018, the DNF team announced the decision to move libdnf from C to C++.[17][18] libdnf is already used by PackageKit, a Linux distribution-agnostic package system abstraction library, even though the library doesn't have most of DNF's features.[19]
Since the launch of Fedora Linux 41, DNF5 is the new default packaging tool. This release features new performance enhancements, updated terminal output, and fully integrated modularity.[20]
Adoption
[edit]DNF has been the default command-line package manager for Fedora since version 22, which was released in May 2015.[11] The libdnf library is used as a package backend in PackageKit,[19] which offers a graphical user interface (GUI). Later, dnfdragora was developed for Fedora 27 as another alternative graphical front-end of DNF.[21][22] DNF has also been available as an alternate package manager for Mageia Linux since version 6 and may become the default sometime in the future.[23]
In Red Hat Enterprise Linux, and by extension, AlmaLinux and Rocky Linux, yum is an alias for dnf.[12]
References
[edit]- ^ 0.6.4-1 for rpm-software-management/dnf dnf on GitHub
- ^ "5.3.0.0". 4 November 2025. Retrieved 5 November 2025.
- ^ "GitHub - rpm-software-management/dnf: Package manager based on libdnf and libsolv. Replaces YUM". GitHub. Retrieved 6 October 2016.
- ^ "GitHub - rpm-software-management/dnf5: Next-generation RPM package management system". GitHub. Retrieved 11 March 2023.
- ^ a b c d "The dnf Open Source Project on Open Hub: Languages Page". Open Hub. Retrieved 2 May 2024.
- ^ a b c d e f g h i "The dnf5 Open Source Project on Open Hub: Languages Page". Open Hub. Retrieved 2 May 2024.
- ^ "DNF". Fedora Project Wiki. Archived from the original on 2018-10-14. Retrieved 2018-05-21.
- ^ "What does DNF stand for". DNF User's FAQ. Archived from the original on 2018-10-14. Retrieved 2018-05-21.
- ^ README.rst · rpm-software-management/dnf on GitHub
- ^ Byfield, Bruce. "Will DNF Replace Yum?". Linux Magazine. Archived from the original on 2015-09-26. Retrieved 2015-05-28.
- ^ a b "Fedora 22 Released, See What's New [Workstation]". WebUpd8. 2015-05-26. Archived from the original on 2015-09-25. Retrieved 2015-05-28.
- ^ a b Matteson, Scott (2019-03-30). "What's new with Red Hat Enterprise Linux 8 and Red Hat Virtualization". TechRepublic. Archived from the original on 2019-09-24. Retrieved 2019-09-24.
- ^ a b c "Dnf Package Manager - Documentation". docs.rockylinux.org. Retrieved 2025-11-24.
- ^ Djere, Rex (2025-10-23). "The Histories, Similarities and Differences of the APT and DNF GNU/Linux Package Managers". Djere.com. Retrieved 2025-11-24.
- ^ a b Edge, Jake (2014-01-15). "DNF and Yum in Fedora". LWN.net. Archived from the original on 2015-09-30. Retrieved 2015-03-29.
- ^ Šilhan, Jan (2016-02-24). "DNF into C initiative started". DNF blog. Archived from the original on 2017-07-02. Retrieved 2017-07-05.
- ^ Mach, Daniel; Mracek, Jaroslav (22 March 2018). "Announcing DNF 3 development". DNF: A Blog of The DNF Team. Archived from the original on September 18, 2018. Retrieved 8 August 2023.
- ^ Edge, Jake (28 March 2018). "DNF 3: better performance and a move to C++". LWN.net. Archived from the original on October 14, 2018. Retrieved 8 August 2023.
- ^ a b Aleksandersen, Daniel (2017-07-05). "Use DNF rather than PackageKit on Fedora". Ctrl blog. Archived from the original on 2017-08-07. Retrieved 2017-08-07.
- ^ "Changes/ReplaceDnfWithDnf5". Archived from the original on 2023-11-12. Retrieved 2023-11-12.
- ^ "Changes/Replace yumex-dnf with dnfdragora - Fedora Project Wiki". fedoraproject.org. Archived from the original on 2021-09-27. Retrieved 2021-09-27.
- ^ "F27 Self Contained Change: Replace Yumex-DNF with dnfdragora - devel - Fedora Mailing-Lists". lists.fedoraproject.org. Archived from the original on 2021-09-27. Retrieved 2021-09-27.
- ^ Larabel, Michael (2016-09-05). "Mageia To Offer DNF, But Will Keep Using URPMI By Default". Phoronix. Archived from the original on 2017-12-06. Retrieved 2017-12-04.
External links
[edit]| dpkg | |
|---|---|
| RPM | |
| Embedded systems |
|
| Distribution-agnostic | |
| Others (binary) | |
| Others (source) | |
| Front-ends | |
| Related topics | |
Italics = inactive or discontinued
| |
.svg){kind=logo} | This free and open-source software article is a stub. You can help Wikipedia by expanding it. |
DNF (software)
View on Grokipediafrom Grokipedia
DNF (Dandified YUM) is an open-source command-line package manager for RPM-based Linux distributions, designed to handle the installation, updating, removal, and querying of software packages while automatically resolving dependencies.[1] It serves as the direct successor to the YUM (Yellowdog Updater, Modified) tool, offering improved performance, reduced memory usage, and enhanced dependency resolution through the libsolv library.[2][3]
Developed by the Fedora Project and the broader RPM Software Management community, DNF was first introduced in Fedora 18 in 2013 as an experimental alternative to YUM, addressing limitations in speed and scalability.[3] It achieved version 1.0 stability in 2015 and became the default package manager in Fedora 22 that same year, with backward compatibility for most YUM commands to ease the transition.[4] In 2025, DNF5 was released as a major rewrite, becoming the default in Fedora 43 and further enhancing performance.[5] Originally written primarily in Python and licensed under the GNU General Public License version 2 or later, DNF5 is implemented in C++ and leverages libdnf5 for core functionality (incorporating librepo for repository metadata handling), along with libsolv for dependency resolution.[6][7]
DNF has been widely adopted across RPM-based distributions, including Red Hat Enterprise Linux (RHEL) starting from version 8, CentOS Stream, Rocky Linux, AlmaLinux, and Amazon Linux 2023, where it replaced YUM as the primary tool for managing software from RPM repositories.[8][9] In addition to basic package operations, it supports advanced features like modular content management (e.g., streams and profiles in RHEL), GPG signature verification for secure downloads, plugin extensibility, and transaction history for rollbacks.[8][1] These capabilities make DNF a robust solution for system administrators, enabling efficient software lifecycle management in enterprise and community environments.[10]
This establishes system-wide defaults without altering repository metadata.[43]
In DNF5, the successor to earlier versions, the configuration structure remains compatible with
Overview
Description
DNF, or Dandified YUM, is a command-line package manager designed for RPM-based Linux distributions such as Fedora and Red Hat Enterprise Linux.[11] It facilitates the installation, updating, removal, and querying of software packages, enabling users to manage software efficiently from the terminal.[12] As the successor to YUM, DNF provides a more modular and performant alternative for handling package operations in these ecosystems.[11] The core purpose of DNF is to automate dependency resolution, ensuring that all required libraries and components are correctly identified and installed during package operations.[1] It manages repositories by fetching packages and their metadata from configured sources, while also handling updates to simplify overall software maintenance on Linux systems.[1] This automation reduces manual intervention, minimizing errors in complex dependency chains common to RPM-based environments. In operation, DNF relies on repositories specified in configuration files, such as those in /etc/yum.repos.d/, to download RPM packages over the network.[13] Once fetched, it integrates these packages with the system's libraries and file structure during installation, supporting secure GPG-signed verification to maintain integrity.[1] Versions 1 through 4 of DNF are implemented in Python, providing extensibility through scripting and plugins.[2] Starting with DNF5, the core has transitioned to C++ for enhanced performance in dependency solving and overall execution speed.[6]Key Features
DNF supports modular repositories, which allow for the organization and delivery of software in discrete units called modules, enabling users to select specific versions or streams of applications without affecting the base system. This design facilitates faster metadata handling through efficient repository structures that include modular metadata alongside standard RPM files, reducing the overhead of parsing large monolithic repositories.[14] A key efficiency feature is the parallel downloading of packages and metadata, configurable via options like max_parallel_downloads, which significantly reduces the time required for updates by fetching multiple files simultaneously from repositories. In DNF5, this extends to parallel metadata downloads, further optimizing initial repository synchronization.[15][16] DNF employs strict dependency resolution powered by SAT (Boolean Satisfiability) solvers from the libsolv library, ensuring that installations are conflict-free by modeling dependencies as logical constraints and finding optimal solutions. This approach provides robust handling of complex dependency graphs, guaranteeing system stability during package operations. The dependency resolution process integrates seamlessly with modular content, allowing for precise version selections.[17] For security, DNF includes built-in GPG signature verification, which checks the authenticity and integrity of packages and repository metadata using imported public keys, preventing the installation of tampered or unsigned content by default.[1] To minimize network usage, DNF implements comprehensive caching mechanisms for both metadata and downloaded packages, storing repository information in /var/cache/dnf and retaining packages via the keepcache configuration option, which allows reuse in subsequent operations or offline scenarios.[12] DNF integrates natively with modules for application streams, enabling the management of multiple concurrent versions of software stacks, such as different releases of Python or Node.js, through commands that enable specific streams and install associated profiles. This feature supports flexible development environments by isolating version-specific dependencies.[18] DNF5, a complete rewrite of the original DNF in C++, delivers substantial performance enhancements, including significantly faster resolution times in benchmarks due to optimized algorithms and reduced overhead compared to the Python-based predecessor. As of Fedora 41 in 2024, DNF5 has become the default package manager, enhancing performance across RPM-based distributions.[19][20]History
Development Origins
DNF originated in 2012 as a Fedora Project initiative to modernize the aging YUM package manager, primarily addressing its performance bottlenecks in handling large repositories where dependency resolution was slow and resource-intensive.[21] YUM's ad-hoc dependency checking methods often resulted in unpredictable outcomes and excessive processing times—reportedly up to four times slower than simple file extraction operations—prompting the need for a more efficient successor.[21] The project was spearheaded by Red Hat developer Aleš Kozumplík, who forked YUM version 3.4 and integrated his Hawkey library as the new backend, wrapping the openSUSE libsolv solver to enable SAT-based dependency resolution.[21][22] The development effort involved the broader Fedora Project team, including contributions from the RPM Fusion community for testing and integration with third-party repositories, alongside upstream enhancements to libraries like libdnf for core functionality. Initial goals focused on accelerating dependency solving speeds, minimizing memory consumption during operations—addressing YUM's high RAM usage in complex scenarios—and fostering greater modularity to support future extensions like package layering.[23] These objectives aimed to create a scalable tool capable of managing growing repository sizes without the inefficiencies that plagued YUM in enterprise and community environments.[21] DNF made its experimental debut in Fedora 18, released in 2013, where it served as an optional alternative to YUM rather than a full replacement, allowing users to test its capabilities during the transition period.[17] Designed explicitly as a drop-in compatible tool, it preserved YUM's command-line interface and configuration syntax for seamless adoption while introducing the Hawkey backend for querying and resolving dependencies more reliably and swiftly.[17] This phased approach ensured stability as the project matured toward becoming the default in later Fedora versions.[21]Major Releases
DNF 1.0 was released in May 2015 with Fedora 22, where it became the default package manager, replacing Yum and introducing the libdnf library for core functionality along with basic modularity concepts.[4][24][25] The DNF 2.x series, developed from 2016 to 2018, introduced advanced module support in Fedora 28 released in May 2018, allowing users to manage versioned application streams for streamlined software delivery.[26][18] DNF 4.x versions, spanning 2019 to 2022, were integrated as the underlying technology for YUM in Red Hat Enterprise Linux 8 upon its release in May 2019, featuring enhancements in error handling, dependency resolution, and repository configuration management.[27] DNF5, whose development began in 2020 and represents a complete rewrite in C++ with direct integration of the libsolv library for superior solver performance and reduced resource usage, debuted as the default package manager in Fedora 41 in October 2024.[28][29] It has since become the default in subsequent releases, including Fedora 42 (April 2025) and Fedora 43 (October 2025).[30] Support for DNF versions 1 through 4 follows the lifecycle of their respective Fedora releases, with transitions to DNF5 beginning in Fedora 41; RHEL continues to use DNF 4.x with support until at least 2029.[30][31]Technical Architecture
Dependency Resolution
DNF employs the libsolv library as its core dependency resolver, which formulates package dependencies as a Boolean satisfiability (SAT) problem to efficiently determine valid installation sets.[17][32] This approach replaces earlier ad-hoc methods with a more robust SAT solver, enabling DNF to handle complex inter-package relationships across large repositories by modeling requirements, conflicts, and alternatives as logical clauses.[21] The resolution process begins with parsing metadata from RPM repositories and the local RPM database using the hawkey library, which interfaces with libsolv to construct a dependency graph.[17] Libsolv then generates a SAT problem instance from this graph, where packages are variables and dependencies form constraints, and applies optimized SAT-solving algorithms to identify the minimal set of packages that satisfies all conditions while minimizing conflicts and upgrades.[32] This results in an optimal transaction set that balances user requests with system stability. DNF distinguishes between strict dependencies (e.g., "Requires") and weak dependencies (e.g., "Recommends" or "Suggests"), with the SAT solver enforcing strict ones as mandatory clauses while treating weak ones as optional unless configured otherwise via thebest option.[15] Obsoletes are modeled as disjunctive choices, allowing the solver to select newer packages that replace older ones, and conflicts are represented as negative clauses that prevent incompatible combinations.[32]
In DNF5, the dependency solver benefits from a complete rewrite in C++ using libdnf5, which integrates libsolv more tightly and yields significant performance gains, such as reducing resolution times for system-wide queries from over 15 seconds in DNF4 to under 3 seconds (as of 2024 benchmarks).[33] These optimizations stem from improved data structures and reduced overhead, though the core SAT solver remains single-threaded; parallelization is applied elsewhere, like repository metadata loading.[28]
Common error cases arise when the SAT solver finds no satisfying assignment, such as "nothing provides" errors, which occur if a required dependency lacks any available provider in the repositories or local system.[34] "Conflicting requests" indicate unsolvable constraints, often due to mutual conflicts between packages or obsoletes that cannot be resolved without violating other dependencies, prompting users to adjust requests or enable additional repositories.[34]
Plugins and Extensions
DNF's extensibility is primarily achieved through its plugin system, which allows users and developers to modify or enhance the package manager's behavior without altering its core codebase. In versions 1 through 4, plugins are implemented in Python and operate by subclassing thednf.Plugin base class, enabling them to hook into various stages of DNF's operation, such as configuration loading, repository resolution, transaction preparation, and post-execution cleanup.[35] These hooks include events like pre_config for initial setup adjustments, resolved for inspecting transactions after dependency resolution, pre_transaction for actions before package installation or removal, and post_transaction for follow-up tasks after completion.[35] Plugins cannot directly modify the core dependency solver logic but can filter search results, add custom metadata to packages, or execute scripts at hooked points to extend functionality.[35]
With the release of DNF5 (default in Fedora since 2024 and as of 2025), the plugin architecture shifted to C++ to align with the rewritten libdnf5 library, introducing two plugin types: LIBDNF5 plugins, which are passive and use hooks to inject logic into library operations (e.g., pre-transaction verification or post-install notifications), and DNF5 CLI plugins, which actively add new commands to the interface (e.g., dnf5 builddep for resolving build dependencies).[36] This change ensures better performance and tighter integration but renders Python plugins from prior versions incompatible, requiring rewrites for continued use.[36] Developers implement these by defining C++ classes that inherit from plugin base interfaces and register hooks via the plugin loader, with configuration handled separately from core DNF settings.[37]
Official plugins for DNF5 are distributed primarily through the dnf5-plugins package, which bundles several utilities to address common administrative needs (as of Fedora 42 in 2025). For instance, the dnf5-plugin-automatic enables scheduled automatic updates, downloads, or reboots based on configurable timers and criteria, often integrated with systemd timers for unattended maintenance.[38] The builddep plugin resolves and installs build-time dependencies for source packages, facilitating development workflows.[39] Similarly, needs-restarting assesses whether a system reboot is required post-update by checking for modified libraries or services, while debuginfo-install fetches debugging symbols for installed binaries to aid in crash analysis.[39] Other core plugins like config-manager allow runtime enabling or disabling of repositories, and download retrieves RPM files without installing them.[39]
Third-party extensions expand DNF's capabilities for specialized environments, such as multimedia handling or enterprise integration. RPM Fusion repositories, for example, include plugins that automatically enable multimedia codecs and proprietary drivers during installation, streamlining access to restricted content.[40] In enterprise settings, custom plugins or scripts—often built on the hook system—integrate DNF with tools like snapshot managers (e.g., for Btrfs or LVM) to create backups before transactions or synchronize with configuration management systems like Ansible.[41]
Plugins for legacy DNF are configured via files in the /etc/dnf/plugins/ directory, where each plugin has a .conf file defining options like enabled=1. The main /etc/dnf/dnf.conf file includes a plugins directive (default: 1) to toggle the entire system, and additional paths can be specified via pluginpath. For DNF5, the plugins option (default: True) in the [main] section of /etc/dnf/dnf.conf enables libdnf5 plugins, with configurations in /etc/dnf/libdnf5-plugins/ (via pluginconfpath) and plugins loaded from /usr/lib64/libdnf5/plugins/ (via pluginpath).[42] This modular setup allows selective enabling to avoid overhead from unused features.
Usage and Configuration
Installation and Setup
DNF is pre-installed by default on Fedora releases starting from version 22 and on Red Hat Enterprise Linux (RHEL) versions 8 and later, providing immediate access to package management functionality without additional steps for users of these distributions.[11][43] For older, end-of-life systems such as RHEL 7 or CentOS 7 (EOL June 2024), manual installation is required by first enabling the Extra Packages for Enterprise Linux (EPEL) repository and then executingyum install dnf (bootstrapping via YUM for the initial DNF package).[44][45][46]
Key prerequisites for DNF include the RPM package manager, which handles the underlying package database and transactions. Versions 1 through 4 of DNF require Python 3 as the runtime environment, while DNF5 shifts to the libdnf C++ library for improved performance and reduced dependencies. Additionally, allocate at least 100 MB of disk space for metadata caches and downloaded packages, though actual usage may vary based on repository size and transaction volume.[47][48][33]
Initial setup involves configuring repositories, typically by editing or adding files in the /etc/yum.repos.d/ directory to define base URLs, enabled status, and GPG key verification for package authenticity. Enable GPG keys for trusted repositories using rpm --import <keyfile> to avoid verification prompts during operations. Conclude setup by running dnf clean all to clear any existing metadata and fetch fresh repository data, ensuring the system is ready for package management tasks.[15][49][11]
When upgrading from YUM on compatible systems, DNF maintains backward compatibility through command-line aliases, where yum symlinks to dnf, allowing seamless transition without altering scripts or habits. Metadata from YUM is automatically migrated due to shared database formats, though users should verify repository configurations post-upgrade to align with DNF's enhanced resolution features.[50][51]
As of 2025, migrating to DNF5—now the default in Fedora 41 and subsequent releases—involves using dnf5 commands alongside legacy dnf (DNF4) during the transition period, with both tools sharing configuration files for minimal disruption. This parallel usage supports testing and gradual adoption, particularly in environments requiring stability before full switchover.[52][33]
Common Commands
DNF provides a command-line interface (CLI) for managing software packages on RPM-based Linux distributions, with commands designed for simplicity and efficiency in handling installations, updates, and queries. Core commands focus on basic package operations, while query and repository management tools aid in discovery and configuration. Advanced features support rollback and history tracking, and DNF5 introduces enhancements for modular environments.Core Commands
Thednf install <package> command installs the specified package along with all required dependencies automatically, resolving conflicts and ensuring system consistency.[12] For system maintenance, dnf update upgrades all installed packages to their latest available versions or targets specific packages if provided, incorporating security patches and feature updates.[12] To uninstall, dnf remove <package> deletes the named package and any dependencies that are no longer needed by other installed software.[12]
Query Commands
Package discovery begins withdnf search <term>, which scans repository metadata for packages matching the given keywords in names, summaries, or descriptions.[12] To view locally installed packages, dnf list installed displays a list of all packages on the system, optionally filtered by name or pattern.[12] For detailed information, dnf info <package> retrieves the package's summary, description, version, size, and dependencies from the repository or local installation.[12]
Repository Management
Thednf repolist command lists all enabled repositories, showing their IDs, names, and status, with options to include disabled or all repositories for comprehensive oversight.[12] To activate a repository, dnf config-manager --enable <repo> sets the specified repository as enabled, allowing access to its packages without editing configuration files manually.[12]
Advanced Commands
For reverting changes,dnf downgrade <package> installs the highest available lower version of the specified package, useful for addressing regressions in updates.[12] Transaction logging is managed via dnf history, which lists past operations, provides details on specific transactions, or allows undoing and redoing them to maintain audit trails.[12]
DNF5 Specifics
In DNF5, thednf5 swap <old> <new> command facilitates module switches by removing the old package or module stream and installing the new one in a single atomic transaction, minimizing downtime during transitions.[53] As of 2025, DNF5 features improved output formatting with enhanced readability, including better alignment and color-coded progress indicators for command results.[54]
Certain commands can be extended through plugins for additional functionality, such as custom repository handling.[12]
Configuration Files
DNF's primary global configuration file is located at/etc/dnf/dnf.conf, which uses an INI format consisting of sections such as [main] for system-wide settings.[15] This file controls behaviors like cache management and network options, with the [main] section specifying the default directory for cached data via the cachedir option, typically set to /var/cache/dnf on most distributions.[15] For instance, the keepcache option, defaulting to False, determines whether downloaded packages are retained after installation; setting it to True preserves them for potential reuse or debugging.[15]
Key options in the [main] section also include bandwidth throttling with the throttle parameter, which limits download speeds (e.g., throttle=1M for 1 megabyte per second) and defaults to 0 for unlimited throughput.[15] Proxy configurations are handled by the proxy directive, specifying a URL like proxy=http://proxy.example.com:8080 if no environment variable is set.[15] Additionally, verbosity is adjusted via debuglevel, ranging from 0 to 10 with a default of 2, allowing finer control over log output (e.g., debuglevel=5 for more detailed traces).[15]
Repository-specific configurations are defined in .repo files under /etc/yum.repos.d/, where each file contains one or more [repo-id] sections identifying the source.[15] Essential directives include baseurl for listing mirror URLs (e.g., baseurl=http://mirror.example.com/fedora/), enabled=1 to activate the repository (defaulting to True), and gpgcheck=1 to enforce GPG signature verification on packages (defaulting to True).[15] These files enable customized package sources while maintaining security and availability controls.
Module streams, which allow selection of specific versions for modular content like programming languages, are configured through YAML files in the /etc/dnf/modules.defaults.d/ drop-in directory.[43] For example, to set Python 3.11 as the default stream, a file such as /etc/dnf/modules.defaults.d/python.yaml can contain:
module: python
[stream](/page/Stream): 3.11
profiles:
- default
module: python
[stream](/page/Stream): 3.11
profiles:
- default
/etc/dnf/dnf.conf in INI format, ensuring seamless adoption across Fedora and compatible distributions as of 2025, with shared settings among components for consistency.[42]
Comparison to YUM
Similarities
DNF maintains significant continuity with its predecessor, YUM, particularly in the command-line interface, to ensure seamless backward compatibility for users. Core operations utilize identical syntax; for instance, the commandyum install <package> is directly equivalent to dnf install <package>, allowing scripts and workflows developed for YUM to function without modification under DNF.[55][56] This compatibility extends to other fundamental commands, such as yum update and dnf update, preserving user familiarity across RPM-based distributions.[57]
The repository configuration format is another area of shared design, with DNF fully supporting the same .repo files used by YUM, typically located in /etc/yum.repos.d/. These files adhere to identical standards for defining repository URLs, GPG keys, and metadata expiration policies, enabling direct reuse without reconfiguration.[15][13] Furthermore, both tools rely on the same RPM metadata formats for package information, ensuring interoperability in repository management and caching.[58]
In terms of transaction handling, DNF and YUM employ a comparable model centered on atomic operations, where installations, updates, or removals are executed as indivisible units to maintain system integrity. Both provide rollback capabilities through a transaction history mechanism; for example, the dnf history undo <ID> command mirrors yum history undo <ID>, allowing reversal of specific transactions recorded in their respective history databases while sharing the RPM database at /var/lib/rpm for package state.[59][60] This facilitates consistent auditing and recovery across both package managers.[61]
Output formatting and logging exhibit strong similarities, with both DNF and YUM producing verbose textual logs during operations, including details on downloaded packages, dependencies, and resolution steps. Progress indicators, such as progress bars for downloads and installations, are present in both, offering visual feedback in terminal sessions that aligns closely in style and information density.[15][62]
DNF integrates seamlessly with the broader RPM ecosystem, just as YUM does, by directly interfacing with the RPM database at /var/lib/rpm for querying, installing, and verifying packages. Tools like rpmbuild for creating RPM packages remain fully compatible, as DNF handles the same binary and source RPM formats without alteration.[61][63] This shared foundation ensures that ancillary utilities, such as rpm for low-level package manipulation, operate identically in conjunction with either manager.[64]