Wielu administratorów wciąż traktuje DNF jak zwykłego następcę YUM-a z nieco odświeżoną składnią. Pod maską kryje się jednak zupełnie nowa architektura. W nowszych wydaniach Fedory domyślny DNF5 porzuca Pythona na rzecz czystego C++ – a ta zmiana mocno wpływa na ogólną wydajność, strukturę wtyczek oraz kompatybilność dotychczasowych skryptów.
DNF vs YUM – to nie tylko inna składnia
DNF zadebiutował jako domyślny menedżer pakietów w Fedorze 22 w maju 2015 roku, a w ekosystemie Red Hat Enterprise Linux zastąpił wysłużonego YUM-a wraz z premierą RHEL 8 w maju 2019 roku. Choć od tamtych wydarzeń minęło już sporo czasu, wciąż pokutuje mit, że cała migracja sprowadza się do zamiany komendy yum install na dnf install. Rzeczywistość szybko weryfikuje to uproszczenie.
YUM był napisany w Pythonie i polegał na własnych, czasem mało wydajnych algorytmach rozwiązywania zależności. DNF4 – wersja znana z RHEL 9 oraz starszych wydań Fedory – opiera się na zewnętrznej bibliotece libsolv, rozwijanej pierwotnie w ramach projektu openSUSE. Przełożyło się to na szybsze i bardziej przewidywalne rozwiązywanie konfliktów, mniejsze zużycie pamięci oraz stabilniejsze API libdnf/hawkey. W DNF4 większość krytycznych zadań wykonuje kod napisany w C z pythonowym wrapperem, a nie czysty Python.
W RHEL 8 i 9 polecenie yum jest jedynie dowiązaniem symbolicznym do dnf. Zapewnia to wygodną kompatybilność wsteczną, ale pod spodem i tak uruchamia się nowy menedżer. Zmienił się format pamięci podręcznej (obecnie przechowywanej w /var/cache/dnf/), logika obsługi błędów oraz kody wyjścia – DNF znacznie rygorystyczniej raportuje wszelkie nieprawidłowości. Jeśli Twoje skrypty administracyjne opierają się na starym API Pythona z czasów YUM-a, samo dowiązanie nie pomoże i konieczne będzie ich przepisanie pod libdnf.
DNF5 – ewolucja w stronę C++
Wraz z premierą Fedory 41 pod koniec 2024 roku, domyślnym menedżerem pakietów został DNF5 – wersja przepisana całkowicie od nowa w C++. W nowszych wydaniach dystrybucji to właśnie to rozwiązanie stanowi standard. Różnicę widać gołym okiem: operacje na pakietach trwają krócej, a zużycie pamięci RAM wyraźnie spadło. Zmieniła się jednak także architektura wtyczek.
Część rozszerzeń znanych z pakietu dnf-plugins-core w DNF4 nie współpracuje bezpośrednio z DNF5. Wymagają one dostosowania lub zastąpienia nowymi, natywnymi modułami. To ważny sygnał dla każdego, kto zajmuje się automatyzacją. Skrypty parsujące tekstowe wyjście dnf za pomocą narzędzi takich jak grep czy awk mogą nagle przestać działać, ponieważ format komunikatów uległ zmianie. Podobnie niektóre aliasy i opcje specyficzne dla starszych wtyczek zostały po prostu usunięte.
Warto pamiętać, że RHEL 9 nadal korzysta ze sprawdzonego DNF4. W środowiskach klasy enterprise stabilność API tej wersji pozostaje kluczowa. Przed wdrożeniem systemów opartych na DNF5 warto dokładnie przetestować wszystkie skrypty administracyjne w odizolowanym środowisku. W czasach, gdy AI przyspiesza kodowanie i automatyzację w terminalu, ręczne zarządzanie pakietami wciąż wymaga solidnych fundamentów i ostrożności przy migracjach.
Bezpieczeństwo, historia transakcji i audyt
Jedną z największych zalet DNF jest precyzyjny audyt i możliwość łatwego cofania zmian. Polecenie dnf history wyświetla chronologiczną listę transakcji wraz z unikalnym identyfikatorem, datą, autorem operacji oraz wywołaną komendą. Cała baza historii znajduje się w katalogu /var/lib/dnf/history/. Możesz przeanalizować szczegóły konkretnej operacji za pomocą dnf history info <ID>, a następnie cofnąć jej skutki przez dnf history undo <ID> lub przywrócić system do stanu sprzed danej zmiany za pomocą dnf history rollback <ID>.
Trzeba jednak pamiętać o istotnym ograniczeniu: operacje undo i rollback zakończą się sukcesem tylko wtedy, gdy starsze wersje pakietów wciąż są dostępne w aktywnych repozytoriach lub w lokalnym cache. Jeśli dany plik RPM został usunięty ze źródła, cofnięcie transakcji może się nie powieść.
DNF pozwala również na selektywne instalowanie poprawek na podstawie oficjalnych biuletynów. Polecenie dnf updateinfo pokazuje dostępne powiadomienia o poprawkach: bezpieczeństwa (RHSA), błędów (RHBA) oraz ulepszeniach (RHEA). Dzięki temu możesz ograniczyć aktualizację systemu wyłącznie do łat bezpieczeństwa za pomocą dnf upgrade --security lub tylko do poprawek błędów poprzez dnf upgrade --bugfix. W DNF5 mechanizm ten zachowano, choć sam format prezentacji danych może się nieznacznie różnić od starszego rozwiązania.
Modułowość i zaawansowane zarządzanie repozytoriami
Wprowadzona w RHEL 8 koncepcja modułowości (appstream) pozwala na instalowanie różnych wersji tego samego oprogramowania w odizolowanych strumieniach – dotyczy to m.in. środowisk Node.js, Ruby czy Python. Do zarządzania nimi służą polecenia dnf module list, dnf module enable <nazwa>:<stream>, dnf module install oraz dnf module reset. W RHEL 9 modułowość jest nadal wspierana, choć jej zakres został nieco ograniczony w porównaniu do poprzedniej wersji systemu.
Praca z zewnętrznymi źródłami wymaga znajomości kilku przydatnych narzędzi. Repozytoria społecznościowe COPR aktywuje się komendą dnf copr enable <user>/<repo>, natomiast standardowy plik konfiguracyjny .repo można dodać za pomocą dnf config-manager --add-repo <URL>. Przed instalacją nieznanego pakietu warto sprawdzić jego zawartość: dnf repoquery -l <pakiet> wskaże listę plików, które trafią do systemu, a dnf repoquery --requires <pakiet> wyświetli jego zależności. Szybki podgląd aktywnych źródeł za pomocą dnf repolist to absolutna podstawa codziennej pracy.
Automatyzacja, praca offline i synchronizacja
W środowiskach odciętych od internetu lub objętych restrykcyjną polityką bezpieczeństwa DNF oferuje elastyczne mechanizmy pracy offline. Polecenie dnf install --downloadonly --downloaddir=/ścieżka <pakiet> pozwala pobrać pliki RPM bez ich natychmiastowej instalacji. Przygotowując aktualizację całej dystrybucji, można skorzystać z dnf system-upgrade download --releasever=<wersja>, a sam proces wdrożenia przeprowadzić bezpiecznie po restarcie komputera.
Do automatycznego pobierania i instalowania poprawek służy narzędzie dnf-automatic, konfigurowane w pliku /etc/dnf/automatic.conf i uruchamiane za pomocą systemd (dnf-automatic.timer). Pozwala ono na bezobsługowe dbanie o stan systemu zgodnie z ustalonym harmonogramem. Jeśli zachodzi potrzeba stworzenia lokalnego zwierciadła repozytorium, pomocne okazuje się polecenie dnf reposync, a narzędzie dnf repodiff pozwala szybko porównać zawartość dwóch różnych źródeł. Podobnie jak pip 26.2 zmienia reguły gry w zarządzaniu zależnościami Pythona, tak i systemowe menedżery pakietów muszą ewoluować, by sprostać wymaganiom nowoczesnych, odizolowanych środowisk.
Pułapki migracyjne i kompatybilność skryptów
Przejście z YUM-a na DNF4 na pierwszy rzut oka wydaje się bezbolesne – dopóki nie przyjrzymy się skryptom. Choć stare polecenia działają dzięki symlinkom, skrypty Pythona bezpośrednio odwołujące się do dawnego API YUM przestaną działać. DNF korzysta z zupełnie innego interfejsu programistycznego, a jego kody wyjścia są znacznie bardziej rygorystyczne.
Z kolei przeskok na DNF5 przynosi nowe wyzwania kompatybilności. Skrypty parsujące tekstowe wyjście mogą wymagać poprawek ze względu na nowy format komunikatów. Część specyficznych opcji wtyczek znanych z DNF4 nie jest już wspierana. W starszej wersji komendy groupinstall oraz group install były traktowane tożsamo, podczas gdy nowsze wydanie bywa bardziej restrykcyjne pod kątem obsługi takich aliasów. W świecie systemów enterprise, gdzie Red Hat i OWASP balansują między szybkością a bezpieczeństwem, stabilność i przewidywalność menedżera pakietów to kwestia kluczowa. Każda zmiana wersji narzędzia wymaga więc wcześniejszego przetestowania procedur w bezpiecznym środowisku testowym.
Podsumowując: współczesny DNF to nie tylko kosmetyczny lifting starego YUM-a. To dojrzały ekosystem, który w wersji DNF5 stawia przed administratorami nowe wymagania w zakresie kompatybilności i struktury skryptów. Dobra znajomość historii transakcji, modułów oraz metod pracy offline to dziś niezbędne elementy w arsenale każdego administratora systemów Linux.
Źródła
- https://www.tecmint.com/dnf-commands-linux/
- https://dnf.readthedocs.io/en/latest/
- https://github.com/rpm-software-management/dnf
- https://github.com/rpm-software-management/dnf5
- https://docs.fedoraproject.org/en-US/quick-docs/dnf/
- https://fedoraproject.org/wiki/Changes/DNF5
- https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_software_with_the_dnf_tool/index
- https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/installing_managing_and_removing_user-space_components/index
Komentarze