Daniel Mach z Red Hata o rozpoczęciu rozwoju menedżera pakietów DNF 5, w którym logika DNF zaimplementowana w Pythonie zostanie przeniesiona do biblioteki libdnf napisanej w C++. Planowane jest, że rozpoczęcie testów DNF 5 nastąpi w czerwcu podczas opracowywania Fedory 33, po czym zostanie dodane do repozytorium Rawhide w październiku 2020 r. i zastąpi DNF 2021 w lutym 4 r. Konserwacja gałęzi DNF 4 będzie kontynuowana w obecnym stanie używany w Red Hat Enterprise Linux 8.
Należy zauważyć, że projekt osiągnął stan, w którym dalsze rozwijanie kodu bez zerwania kompatybilności na poziomie API/ABI jest prawie niemożliwe. Dzieje się tak głównie z powodu znaczenie PackageKit i niemożność opracowania libdnf bez zmiany API „libhif”. Jednocześnie, pomimo zamiaru zmiany API, za główny priorytet uważa się utrzymanie kompatybilności wstecznej na poziomie interfejsu wiersza poleceń i API.
Wsparcie dla Python API w DNF zostanie zachowane, ale logika biznesowa napisana w Pythonie zostanie przeniesiona do biblioteki libdnf (C++), co zapewni identyczne działanie menedżera pakietów w dystrybucji. Rozwój będzie skupiony wokół API C++, a API Pythona będzie automatycznie generowane w formie bazującego na nim wrappera.
Wiązania dla Go, Perla i
Rubin. Po ustabilizowaniu API C++, na jego podstawie zostanie przygotowane API C, do którego zostanie przeniesione RPM-ostree. Interfejs API języka Python zostanie usunięty i zastąpiony przez API Pythona.
Podstawowa funkcjonalność DNF zostanie zachowana. Ze względu na duży zestaw testów (około 1400 testów) oczekuje się, że przeróbka API nie będzie miała wpływu na interfejs wiersza poleceń dla użytkowników końcowych. Analiza argumentów i dane wyjściowe mogą się nieznacznie zmienić, ale zmiany te będą dobrze udokumentowane. W okrojonej wersji , używanych w kontenerach, planuje się wdrożenie podzbioru możliwości DNF; osiągnięcie pełnej parytetu funkcjonalności nie jest brane pod uwagę.
Zamiast Zostanie utworzona nowa usługa DBus zapewniająca interfejs do zarządzania pakietami i aktualizacjami dla aplikacji graficznych. Usługa ta planowana jest od podstaw, więc jej utworzenie może zająć dużo czasu. PackageKit nie był ostatnio rozwijany i od 2014 r. znajduje się w trybie konserwacji z powodu utraty przydatności. Wraz z rozwojem systemów Snaps i Flatpak dystrybucje tracą zainteresowanie PackageKit, na przykład nie jest on już dostępny w kompilacjach . Warstwa abstrakcji do zarządzania pakietami jest w dużej mierze zapewniana przez natywne Centra kontroli aplikacji GNOME i KDE, które umożliwiają instalację pakietów flatpak na poziomie indywidualnego użytkownika. Ujednolicony systemowy interfejs API do uzyskiwania listy zainstalowanych pakietów nie jest już tak przydatny jak wcześniej.
Źródło: opennet.ru