Recently Fedora developers made known their intentions to migrate the distribution to the new package manager called “Microdnf” instead from the package manager "DNF" that is currently used.
The first step on the path to migration will be a major update to Microdnf, planned for Fedora 38, which will come close in functionality to DNF and even exceed it in some areas.
It is mentioned that the intentions to carry out this migration is due to the key difference between Microdnf and DNF is the use of C instead of Python for development, which allows you to get rid of a lot of dependencies.
At one point, DNF replaced Yum, which was written entirely in Python, and in DNF, performance-demanding low-level functions were rewritten and moved to separate hawkey, librepo, libsolv, and libcomps C libraries, but the framework and the high-level components remained in the Python language.
Microdnf was originally developed as a simplified version of DNF for use in Docker containers that did not require Python to be installed. Now the Fedora developers plan to bring Microdnf to the level of DNF functionality and eventually completely replace DNF with Microdnf.
A major update to Microdnf is the first step in the evolution of package management in Fedora. The new microdnf has the ambition to provide all the core features of DNF without losing its minimal footprint.
Microdnf is based on libdnf5 library, developed as part of the DNF 5 project. DNF 5 aims to unify existing low-level libraries, rewrite the remaining Python package management operations in C++, and move core functionality to a separate library with the creation of a binding around this library to preserve the Python API.
MICRODNF significantly improves the user experience and will provide all the important features of DNF in the future. It will also maintain all the advantages of the original MICRODNF, such as the minimum size required for containers.
The new version of Microdnf will also use the background process DNF Daemon, replacing the PackageKit functionality and providing an interface for managing packages and updates in graphical environments. Unlike PackageKit, the DNF Daemon will only support the RPM format.
Microdnf, libdnf5, and the DNF Daemon are scheduled to ship alongside the traditional DNF toolkit in the first phase of implementation. Once the project is complete, the new package will replace packages like dnf, python3-dnf, python3-hawkey, libdnf, dnfdragora, and python3-dnfdaemon.
Of the areas where Microdnf is superior to DNF, it stands out: a more visual indication of the progress of operations; improved transaction table implementation; the ability to display information in reports about completed transactions that is issued by packaged scriptlets (scriptlets); support for using local RPM packages for transactions; more advanced input completion system for bash; support for running the builddep command without installing Python on the system.
Among the disadvantages changing the distro's package manager to Microdnf is the change in the structure of the internal databases and the processing of the separate database from DNF, which will not allow you to see transactions with packages made in DNF in Microdnf and vice versa.
Packages previously installed with DNF will be treated as "user installed from dnf history" after migrating to Microdnf, and uninstalling a package installed by another package manager will not remove unused dependencies associated with it. Also, Microdnf does not plan to maintain 100% DNF support at the command level and command line options.
It is noted that the new version of Microdnf will support all the main features of DNF, but at the same time retain high performance and compactness.
Finally, if you are interested in being able to know more about it, you can consult the details in the following link.
I'm new to programming, and enthusiastic about Linux. I have never used Fedora because I always have a problem with the installation and end up with Debian (and derivatives) or OpenSUSE. But I think I understand the importance in the Linux world, and how relevant what happens in Fedora.
My doubt comes from the idea of substituting Python for C/C++, why implement with a low-level language that has been highly criticized for its variants and its poorly defined standard? I understand a little the change from an interpreted language to a compiled one, but I do not understand the jump to a language for which I have seen that it is sought to use less in some areas. Wouldn't it be better to have used Rust or C# ?
I do not criticize the decisions of the people of Fedora, but seek to understand how the world of programming advances. I'm learning Python and JS on the web, and thought I'd jump back into C/C++ for the basics, so this note seems like it might help me with focus.
Thank you so much! And excellent work as always to the people of <•DesdeLinux