Daniel Mach from Red Hat on the start of development for the DNF 5 package manager, which will transfer the DNF logic implemented in Python to the C++ library libdnf. Testing for DNF 5 is planned to start in June during the development of Fedora 33, after which it will be added to the Rawhide repository in October 2020 and replace DNF 4 in February 2021. Maintenance of the DNF 4 branch will continue as it is used in Red Hat Enterprise Linux 8.
It is noted that the project has reached a state where continuing the development of the code without breaking API/ABI compatibility is nearly impossible. This is mainly due to relevance of PackageKit and the inability to develop libdnf without changing the API of 'libhif'. Despite the intention to change the API, maintaining backward compatibility at the command line interface and API levels is stated as a primary priority.
Support for Python API in DNF will remain, but the business logic written in Python will be transferred to the libdnf (C++) library, which will ensure the package manager operates identically in the distribution. Development will focus on the C++ API, and the Python API will be automatically generated as a wrapper based on it.
Similarly, bindings for Go, Perl, and
Ruby will be formed. After the stabilization of the C++ API, a C API will be prepared based on it, to which rpm-ostree will be migrated. The Python API will be removed and replaced with Python API.
The core functionality of DNF will be preserved. Thanks to a large test suite (about 1400 tests), it is expected that the API overhaul will not affect the command line interface for end users. The parsing of arguments and output may change slightly, but these changes will be well-documented. In the stripped-down version, , used in containers, a subset of DNF capabilities is planned to be implemented; achieving full parity in functionality is not being considered.
Instead of A new DBus service will be created, providing an interface for managing packages and updates for graphical applications. This service is planned to be developed from scratch, so its creation may take a significant amount of time. PackageKit has not been actively developed for some time and has been in maintenance mode since 2014 due to a loss of relevance. With the rise of Snap and Flatpak systems, distributions are losing interest in PackageKit; for example, it is no longer included in builds. . The level of abstraction for package management is largely provided by the built-in application management centers of GNOME and KDE, which allow flatpak packages to be installed at the individual user level. A unified system API for retrieving a list of installed packages is becoming less useful than it once was.
Source: opennet.ru
