Fedora 39 planuje domyślnie używać DNF5

Fedora Linux 39 planuje używać DNF5

Fedora Linux 39 planuje domyślnie używać DNF5, aby uzyskać lepszą wydajność

Komitet inżynieryjny i sterujący Fedory (FESCo) ogłasza, że ​​w Fedorze 39 zespół zarządzający prawdopodobnie zastąpi DNF, libdnf i dnf-automatic cz nowym narzędziem do pakowania DNF5 i biblioteką wsparcia libdnf5. DNF5 powinien poprawić wrażenia użytkownika i zapewnić lepszą wydajność zarządzania oprogramowaniem w Fedorze Linux.

DNF to menedżer pakietów oprogramowania który instaluje, aktualizuje i usuwa pakiety w Fedorze i jest następcą YUM (zmodyfikowany Yellow-Dog Updater). DNF ułatwia utrzymanie pakietów poprzez automatyczne sprawdzanie zależności i określanie działań wymaganych do zainstalowania pakietów. Ta metoda eliminuje potrzebę ręcznego instalowania lub aktualizowania pakietu i jego zależności za pomocą polecenia rpm.

Jeśli chodzi o nowe funkcje DNF5, wyróżniają się:

  • Pełny menedżer pakietów bez konieczności używania Pythona
  • najmniejszy system
  • Szybciej
  • Zastępuje DNF i Microdnf
  • Ujednolicone zachowanie w całym stosie zarządzania oprogramowaniem
  • Nowe wtyczki Libdnf5 (C++, Python) będą miały zastosowanie do DNF5 i Dnf5Daemon.
  • Wspólne ustawienia
  • DNF/YUM był rozwijany przez dziesięciolecia z wpływem wielu stylów i konwencji nazewnictwa (opcje, ustawienia, opcje, polecenia)
  • Może stanowić alternatywę dla PackageKit for RPM (unikalny backend PackageKit), jeśli jest wbudowany w Desktop.
  • Kompatybilność z grupą Modularity i Comps
  • Ważne ulepszenia w bazie kodu
  • Oddzielenie stanu systemu od bazy danych historii i /etc/dnf/module.d

W dnf-4 lista zainstalowanych pakietów przez użytkownika oraz listę zainstalowanych grup, a także listę zainstalowanych pakietów tych grup, są obliczane jako agregacja historii transakcji. W dnf5 będzie przechowywany osobno, który ma wiele zalet, z których nie najmniejszą jest fakt, że baza danych historii będzie wykorzystywana wyłącznie w celach informacyjnych i nie będzie określać stanu systemu (czasami ulega uszkodzeniu itp.). Dane przechowywane w /etc/dnf/module.d nie powinny umożliwiać zapisu przez użytkownika, a ich format jest niewystarczający (brak informacji o zainstalowanych pakietach z zainstalowanymi profilami).

DNF5 jest wciąż w fazie rozwoju a niektóre funkcje lub opcje nie są jeszcze dostępne. Już jest praca do wykonania przy wdrażaniu modularności, wewnętrzne przechowywanie danych związanych z historią i stanem systemu oraz dokumentacją i stronami podręcznika. DNF5 można przetestować z repozytorium za pomocą nocnych kompilacji.

DNF5 wycofa wtyczki dnf, yum, dnf-automatic, yum-utils i DNF (rdzeń i dodatki) python3-dnf i LIBDNF (libdnf, python3-hawkey) zostaną przestarzałe z pakietami fedora-obsolete-packages, a ponadto zapewnią dowiązanie symboliczne do /usr/bin/dnf, dzięki czemu użytkownicy zobaczą zastąpienie jako aktualizację do DNF z ograniczonymi, ale udokumentowanymi zmianami składni. DNF5 zapewni niektóre obsługiwane aliasy poleceń i opcje poprawiające adopcję DNF5.

Propozycja zmiany podsumowuje sytuację w następujący sposób:

  1. Nowy DNF5 znacznie poprawi wrażenia użytkownika i wydajność. To zastąpienie jest drugim krokiem w aktualizacji stosu zarządzania oprogramowaniem Fedory. Bez tej zmiany będzie kilka narzędzi do zarządzania oprogramowaniem (DNF5, stary Microdnf, PackageKit i DNF) opartych na różnych bibliotekach (libdnf, libdnf5), które zapewnią inne zachowanie i nie będą udostępniać historii. Możliwe jest również, że DNF ma ograniczone wsparcie programistów. Rozwój DNF5 został ogłoszony na liście Fedory-Devel w 2020 roku.
  2. DNF5 usuwa kod Pythona dla mniejszego systemu, szybsze działanie i zastąpienie istniejących narzędzi DNF i microdnf. DNF5 ujednolica również zachowanie stosu zarządzania oprogramowaniem, wprowadza nowego demona jako alternatywę dla PackageKit for RPM i powinien być znacznie bardziej wydajny. Oczekuj wyższej wydajności przeglądania repozytorium, operacji wyszukiwania, zapytań RPM i udostępniania metadanych.

Propozycja zmiany wciąż wymaga zatwierdzenia przez Komitet ds. Inżynierii i Sterowania Fedory, ale biorąc pod uwagę zaangażowanie Red Hata w DNF(5), można założyć, że zostanie on zatwierdzony i, miejmy nadzieję, ukończony na czas przed cyklem Fedory 39

źródło: https://fedoraproject.org


Zostaw swój komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

*

*

  1. Odpowiedzialny za dane: Miguel Ángel Gatón
  2. Cel danych: kontrola spamu, zarządzanie komentarzami.
  3. Legitymacja: Twoja zgoda
  4. Przekazywanie danych: Dane nie będą przekazywane stronom trzecim, z wyjątkiem obowiązku prawnego.
  5. Przechowywanie danych: baza danych hostowana przez Occentus Networks (UE)
  6. Prawa: w dowolnym momencie możesz ograniczyć, odzyskać i usunąć swoje dane.