Fedora Linux developers aim to transition the distribution to the new Microdnf package manager instead of the currently used DNF. The first step towards this migration will be the significant update to Microdnf planned for the release of Fedora Linux 38, which will bring it closer in functionality to DNF and in some areas even surpass it. It is noted that the new version of Microdnf will support all core features of DNF while maintaining high performance and compactness.
The key difference between Microdnf and DNF is the use of the C programming language for development instead of Python, which eliminates a large number of dependencies. Initially, Microdnf was developed as a stripped-down version of DNF for use in Docker containers, requiring no installation of Python. Now, Fedora developers plan to elevate Microdnf to the level of DNF and eventually fully replace DNF with Microdnf.
Microdnf is based on the libdnf5 library, which is being developed as part of the DNF 5 project. The main idea behind DNF 5 is to rewrite the fundamental package management operations in C++ and separate them into a standalone library, creating a wrapper around this library to maintain the Python API.
The new version of Microdnf will also utilize a background process called DNF Daemon, which replaces the functionality of PackageKit and provides an interface for package and update management in graphical environments. Unlike PackageKit, DNF Daemon will only support the RPM format.
Microdnf, libdnf5, and DNF Daemon are planned to be delivered alongside the traditional DNF toolkit during the initial implementation phase. Once the project reaches full readiness, the new combination will replace packages such as dnf, python3-dnf, python3-hawkey, libdnf, dnfdragora, and python3-dnfdaemon.
Among the areas where Microdnf surpasses DNF are: clearer progress indication during operation execution; improved implementation of transaction tables; the ability to output information from scripts embedded in packages (scriplets) in transaction reports; support for using local RPM packages in transactions; a more advanced input autocomplete system for bash; support for executing the builddep command without installing Python on the system.
Among the downsides of transitioning the distribution to Microdnf is the change in the structure of internal databases and the separation of database handling from DNF, which will prevent Microdnf from viewing transactions with packages executed in DNF and vice versa. Additionally, Microdnf does not intend to maintain 100% compatibility with DNF in terms of commands and command-line options. There will also be some discrepancies in behavior. For instance, removing a package will not result in the removal of associated dependencies that are not used by other packages.
Source: opennet.ru
