Fedora is a meticulously polished distribution in every aspect, rightfully earning its place among the top Linux ones. However, its Achilles’ heel is the package manager it employs, which feels outdated by today’s standards.
Its usage can test a user’s patience, as its performance lags notably behind Debian’s speedy APT. And comparing it to the swift efficiency of Arch’s Pacman is, frankly, not even a fair contest. However, this could all change in Fedora 41.
The Proposal
The Fedora Project has announced a proposal to switch its default package manager from DNF to DNF5 in the upcoming Fedora 41, expected for release around mid-October.
Spearheaded by Jan Kolarik and Jaroslav Mracek of Red Hat, this proposed change is currently under public review and awaits approval from the Fedora Engineering Steering Committee (FESCo).
DNF5: Features and Improvements
DNF5 promises significant improvements over the current version. It aims to enhance the user experience by offering faster query processing and a reduced footprint.
This means it will not require Python dependencies and will help eliminate metadata redundancy by sharing metadata between dnf5 and the new dnf5daemon. Here are the main benefits to expect.
- Enhanced Performance: DNF5 promises faster repository metadata processing and improved package query operations, aiming to save users precious seconds during package management tasks.
- Reduced System Footprint: By eliminating Python dependencies and merging the functionalities of DNF and MicroDNF, DNF5 offers a significantly smaller installation size, reducing metadata redundancy.
- Unified Experience: Fedora aims to provide a consistent package management experience across all platforms, with DNF5 serving as the sole package manager for servers, workstations, and containers.
Looking Ahead
The DNF team has outlined a meticulous plan for those concerned about the transition to ensure a smooth upgrade path. Upon system upgrade or DNF5 installation, the DNF5 package will automatically replace the existing DNF package.
Moreover, backward compatibility for the yum command and a new daemonized service, dnf5daemon, are included to maintain a seamless user experience.
However, for all this to happen, the Fedora Engineering Steering Committee (FESCo) must first approve the proposal before it can become a reality. Currently, it is in its second iteration, following extensive community feedback gathered from its initial attempt.
To wrap up, it’s worth noting that discussions about DNF5 taking over as the default package manager began around a year and a half ago to introduce it in Fedora 39.
Clearly, that transition didn’t take place, and even the upcoming Fedora 40 release, slated for next month, has avoided implementing this significant change.
Nevertheless, there’s a strong sense of optimism that the proposal for DNF5 this time will be green-lighted, paving the way for its anticipated debut in Fedora 41. The proposal’s entire content can be seen here.
DNF5 already available to (optionally) install for F39 in the normal repository. This is the first command I use for new installs – sudo dnf install dnf5. Makes a world of difference performance-wise for those who (obsessively) update packages daily (IMHO).
Good to know. Thanks for the information!
Best,
Bobby
All sounds great and it’s a real shame they couldn’t get it in for F40 release.
But the speed of dnf is perfectly acceptable in my opinion. It’s not like you need to go away to restaurant while it completes the job.
However, I really do miss the feature you see in other package managers which adds colour notes during a package search, one which highlights which packages you actually already have installed. I also which “dnf update” just got updated data from the repo and presented it to you in a nice useful fashion, and then the admin needs to run “dnf upgrade” to actually upgrade packages. This just makes sense.
Hi, I don’t know if this is what you mean for “dnf update” and “dnf upgrade” separation but there’s a “dnf check-update” operation that shows what would be upgraded.
If you mean equivalents to “apt update” and “apt upgrade/dit-upgrade/full-upgrade” then you could use “dnf makecache” and “dnf –cacheonly update/upgrade” (or “dnf -C update/upgrade” for shorter)..