After the launch of Fedora 39, DNF5 sparked discussions in the Linux community regarding its amazing features, performances, and other benefits compared to the current DNF.
Given Fedora Engineering’s confidence and the likely agreement of FESCo, it is likely that it will become the official default package manager for Fedora systems after the release of Fedora 41.
If you’re a casual Linux user, you may have recently come across the term DNF5 and wondered what it is and why you should care. This article aims to provide you with insight into DNF5, its benefits, comparisons between current DNF and DNF5, and command-line usage examples.
What is DNF5 in Fedora Linux?
The new DNF5 is a collaborative effort between the Fedora and Red Hat teams to deliver a significantly improved version of the package manager that can offer an exceptional user experience with enhanced performance.
The first time DNF5 came to the spotlight was when it was announced on the Fedora-Devel list in 2020. Most likely, after the launch of Fedora 41, old tools such as DNF, YUM, Libdnf, and DNF-AUTOMATIC are expected to be replaced by the DNF5 and new Libdnf5 library.
Unlike current DNF, which is basically written in Python, DNF5 is built from scratch in C/C++ to adapt to smaller systems, deliver faster performance, and introduce a new daemon (named dnf5daemon) as an alternative to the PackageKit library for desktop environments such as GNOME and KDE.
What does Current DNF Lack that DNF5 Fulfills?
Now, a curious mind might wonder why this upgrade is so important; for them, the simple answer is that a significant portion of current DNF was primarily written in Python, causing it to become sluggish over time as new features were added.
The introduction of MicroDNF, a minimal version of DNF written in C, aimed to provide all the features of DNF. It marked Fedora’s initial step toward enhancing the user experience and the performance of their default package manager, eventually leading to the launch of DNF5.
Features (or Benefits) of DNF5
The DNF5 offers many features, and I attempted to provide a glimpse of them in the list below:
- A fully-featured package manager written in C/C++ from scratch without requiring Python.
- It has a smaller installation size compared to the current DNF. It occupies 114 MB, while the installation size is 165 MB.
- Optimizes the download of metadata, including the optional download of filelists, which can be configured from both commands and configuration files.
- DNF5 will combine DNF and Microdnf, reducing the number of software management tools in Fedora.
- Commands such as DNF, YUM, and MICRODNF will now be linked to DNF5.
- DNF5 ensures a consistent user experience across different environments, including workstations, servers, and containers.
- Introduces a new alternative to PackageKit for RPMs, with support for Modularity and Comps groups.
- New Libdnf5 plugins written in C++ and Python are introduced that are applicable to DNF5 and Dnf5Daemon.
- DNF5 ensures shared configurations, eliminating inconsistencies present in DNF4, where not all configurations were honored by PackageKit and Microdnf.
- Performance improvements in loading repositories, advisory operations, RPM queries, and smart sharing of metadata between DNF5 and the daemon.
- Shared plugins and the removal of functional duplicates contribute to a decrease in maintenance costs in the long term.
- It fully integrates modularity into LIBDNF5 workflows, addressing limitations in compatibility with other tools like PackageKit.
- DNF5 separates the system state from the history DB and “
/etc/dnf/module.d
“, offering benefits like improved data integrity. - Great bash completion (better than what current DNF has).
The feature is quite interesting, isn’t it? Now, let’s see what effect will happen to a normal user after these changes.
What is the Impact of DNF5 on the Users Experience?
The user experience, essentially how users operate their Fedora system, doesn’t show a significant majority of difference; however, those attached to the command-line will be notably affected by these changes.
Here are some points to consider regarding the impact on the user experience:
- The changes will primarily affect command-line users of DNF and also take into consideration the previous features as an impact on the user experience.
- The symlink “
/usr/bin/dnf
” will be pointed to “/usr/bin/dnf5
“. - There will be some differences in transaction summaries and outputs, and users may need to adjust to the new syntax and options introduced in DNF5.
- The transaction table in DNF5 will contain information about the version of the upgraded package, which differs from DNF4.
- The proposal mentions that DNF and YUM must be obsoleted because DNF5 will provide symlinks to DNF and YUM. However, the original dnf-3 binary will remain on the system, ensuring backward compatibility for users who may need it.
Now, let’s see how you can install, enable, and test DNF5 on your current Fedora system.
How to Install, Enable, and Test DNF5 in Fedora
Before you proceed to install, enable, and test DNF5, first upgrade your current Fedora system to the latest version, and then follow the steps below one by one.
1. Open your terminal and enable the DNF5-unstable Copr repository by running.
$ dnf copr enable rpmsoftwaremanagement/dnf5-unstable
Output:
2. Then, run to install “dnf5
” and “dnf5-plugins
” in your Fedora system.
$ sudo dnf install dnf5 dnf5-plugins
Output:
3. Verify that DNF5 is successfully installed and accessible from the command line.
$ which dnf5
#OR
$ dnf5 --version
Output:
Now, you can access DNF5 using the “dnf5
” command, and yes, you can go further and create a “dnf
” symlink pointing to “/usr/bin/dnf5
“, but I strongly do not recommend you doing this.
A Few Examples of DNF5 Command-Line Usage
If you have experience with the current DNF command-line usage, the transition for you is a piece of cake, as most of the popular options are still available and accessible in DNF5.
However, I’ve listed a few commands in DNF5 along with their descriptions.
#Upgrade system and packages to the latest version.
$ dnf | dnf5 upgrade [PACKAGE-NAME]
#Search for available packages in the system repository.
$ dnf | dnf5 search [PACKAGE-NAME]
#Install a new package by specifying its name.
$ dnf | dnf5 install [PACKAGE-NAME]
#Remove installed packages by specifying their names.
$ dnf | dnf5 remove [PACKAGE-NAME]
#Synchronize the installed packages with the latest versions available in the repositories for the current Fedora release.
$ dnf | dnf5 distro-sync [PACKAGE-NAME]
#Query information about a specified package from the DNF package repositories.
$ dnf | dnf5 repoquery [PACKAGE-NAME]
#Display information about packages that match the specified package specification.
$ dnf | dnf5 list [PACKAGE-NAME]
#Retrieve detailed information about a specified package.
$ dnf | dnf5 info [PACKAGE-NAME]
#Regenerate the metadata cache for the DNF package manager.
$ dnf | dnf5 makecache
#Display a list of repositories along with information about the number of packages available in each repository.
$ dnf | dnf5 repolist
#Display information about the repositories configured on the system.
$ dnf | dnf5 repoinfo
That’s it; the rest of the command-line examples not listed above can be easily independently tested by you.
Final Word
I hope you find this article helpful. If you have any questions or if you find any mistakes in the article, please inform us in the comment section.
Till then, peace!
Hi,
I have an alias for dnf that I use to upgrade my fc41 system. It’s args are rejected by the “new” dnf. Sigh. I’m looking for a way to continue using them or achieving the same result. I’m having difficulty doing this. Here are the options I use:
–allowerasing –noautoremove –skip-broken
Is what I’m looking for missing in these docs? Am I missing something? Maybe it would be useful to have a section describing these and any others and what their replacement(s) would be. I would be very happy to read such a section.
Best regards… and THANKS for these cool docs,