Daniel Mach z firmy Red Hat o rozpoczęciu prac nad menedżerem pakietów DNF 5, w którym logika DNF napisana w języku Python zostanie przeniesiona do biblioteki libdnf napisanej w C++. Testowanie DNF 5 planowane jest na czerwiec w trakcie rozwoju Fedora 33, a następnie w październiku 2020 roku ma zostać dodane do repozytorium Rawhide, a w lutym 2021 roku zastąpi DNF 4. Utrzymanie gałęzi DNF 4 będzie kontynuowane, ponieważ jest ona używana w Red Hat Enterprise Linux 8.
Zauważono, że projekt osiągnął stan, w którym prawie niemożliwe jest kontynuowanie rozwoju kodu bez naruszania zgodności na poziomie API/ABI. Głównie jest to związane z aktualności PackageKit i brakiem możliwości rozwoju libdnf bez zmiany API 'libhif'. Przy tym, mimo zamiaru zmiany API, jako główne priorytety wskazano zachowanie wstecznej kompatybilności na poziomie interfejsu wiersza poleceń i API.
Wsparcie dla API Pythona w DNF zostanie zachowane, ale logika biznesowa napisana w Pythonie zostanie przeniesiona do biblioteki libdnf (C++), co pozwoli zapewnić identyczność działania menedżera pakietów w dystrybucji. Rozwój skoncentruje się wokół C++ API, a Python API będzie automatycznie generowane w formie wiązania na jego podstawie.
Podobnie zostaną utworzone wiązania dla Go, Perla i
Rubiego. Po ustabilizowaniu C++ API na jego podstawie zostanie przygotowane również C API, na które zostanie przetłumaczone rpm-ostree. API Pythona zostanie usunięte i zastąpione API Pythona.
Podstawowa funkcjonalność DNF zostanie zachowana. Dzięki dużemu zbiorowi testowemu (około 1400 testów) oczekuje się, że przeróbka API nie wpłynie na interfejs wiersza poleceń dla końcowych użytkowników. Możliwe, że nieco zmieni się analiza argumentów i ich wyświetlanie, ale te zmiany będą dobrze udokumentowane. W uproszczonej wersji , stosowanej w kontenerach, planuje się zrealizować podzbiór możliwości DNF, osiągnięcie pełnego parytetu funkcjonalności nie jest rozważane.
Zamiast Zostanie utworzona nowa usługa DBus, która zapewni interfejs do zarządzania pakietami i aktualizacjami aplikacji graficznych. Usługa ta będzie opracowywana od podstaw, więc jej stworzenie może zająć dużo czasu. PackageKit w ostatnich latach nie był rozwijany i od 2014 roku jest w trybie utrzymania z powodu utraty aktualności. Wraz z rozwojem systemów Snaps i Flatpak dystrybucje tracą zainteresowanie PackageKit, na przykład nie jest już dostarczany w zestawach. . Poziom abstrakcji dla zarządzania pakietami w dużym stopniu zapewniają wbudowane centra zarządzania aplikacjami GNOME i KDE, które pozwalają na instalację pakietów flatpak na poziomie poszczególnych użytkowników. Ujednolicony systemowy interfejs API do uzyskiwania listy zainstalowanych pakietów staje się mniej użyteczny niż wcześniej.
Źródło: opennet.ru
