Daniel Mach of Red Hat about the beginning of the development of the DNF 5 package manager, in which the DNF logic implemented in Python will be ported to the libdnf library written in C ++. DNF 5 testing is scheduled to begin in June during the development of Fedora 33, followed by adding Rawhide to the repository in October 2020 and replacing DNF 2021 in February 4. The DNF 4 branch will continue to be maintained as it is used in Red Hat Enterprise Linux 8.
It is noted that the project has reached a state in which it is almost impossible to continue development of the code without breaking compatibility at the API / ABI level. This is mainly due to the relevance of PackageKit and the impossibility of developing libdnf without changing the "libhif" API. At the same time, despite the intention to change the API, maintaining backward compatibility at the level of the command line interface and API is called as the main priority.
Support for the Python API in DNF will be retained, but business logic written in Python will be moved to the libdnf (C++) library, which will ensure that the package manager works identically in the distribution. Development will be centered around the C++ API, and the Python API will be automatically generated in the form of a wrapper based on it.
Bindings for Go, Perl and
ruby. After the stabilization of the C ++ API, the C API will be prepared on its basis, to which rpm-ostree will be transferred. The Python API will be removed and replaced with Python API.
The core functionality of DNF will be preserved. Due to the presence of a large test suite (about 1400 tests), it is expected that the API redesign will not affect the command line interface for end users. Argument parsing and output may change slightly, but these changes will be well documented. In a truncated version used in containers, it is planned to implement a subset of DNF features, achieving full parity in functionality is not considered.
Instead of a new DBus service will be created to provide an interface for managing packages and updates for graphical applications. This service is planned to be developed from scratch, so its creation may require a lot of time. PackageKit has not been developed lately and has been in maintenance mode since 2014 due to being out of date. With the advancement of Snaps and Flatpak systems, distributions are losing interest in PackageKit, for example, it is no longer shipped in assemblies . The abstraction layer for package management is largely provided by the native GNOME and KDE Application Control Centers, which allow you to install flatpak packages on a per-user basis. The unified system API for listing installed packages is not as useful as it used to be.
Source: opennet.ru