apt na dnf: odpowiedniki poleceń w systemach RHEL

Krótka odpowiedź

Przejście z apt na dnf to głównie zmiana słownictwa. apt install nginx staje się dnf install nginx. apt remove nginx staje się dnf remove nginx. apt update nie posiada bezpośredniego odpowiednika, ponieważ dnf samodzielnie odświeża metadane repozytoriów, gdy kopia w pamięci podręcznej staje się nieaktualna. Łatwiejsza część tłumaczenia zajmuje jeden ekran. Część praktyczna obejmuje cztery operacje, które nie mają bezpośredniego odwzorowania: dodawanie repozytorium, wycofywanie transakcji, instalację grupy pakietów oraz uruchamianie automatycznych aktualizacji.

Każde poniższe polecenie jest przeznaczone do wykonania na własnym serwerze. Przed udzieleniem odpowiedzi y należy zapoznać się z podsumowaniem transakcji wyświetlanym przez dnf, szczególnie w przypadku usuwania pakietów.

Które dystrybucje używają dnf, a które apt

dnf jest menedżerem pakietów w systemach Fedora, Red Hat Enterprise Linux (RHEL) oraz w systemach bazujących na RHEL: Rocky Linux, AlmaLinux i CentOS Stream. apt jest menedżerem pakietów w systemie Debian oraz we wszystkich systemach wywodzących się z Debiana, co w przypadku VPS niemal zawsze oznacza Ubuntu. Nie ma trzeciej odpowiedzi. Jeśli lista obrazów u dostawcy zawiera Rocky Linux lub AlmaLinux, otrzymasz dnf. Jeśli zawiera Ubuntu, otrzymasz apt.

Format pakietów jest powiązany z narzędziem. dnf instaluje pliki .rpm, a jego baza danych to rpm. apt instaluje pliki .deb, a jego baza danych to dpkg. Dlatego tak wiele stron instalacyjnych dostawców posiada osobne zakładki dla każdej rodziny systemów i dlatego plik .deb pobrany ze strony wydania projektu jest bezużyteczny w systemie Rocky Linux.

Niezależnie od wybranej rodziny, pierwsze logowanie wymaga wykonania tych samych czynności. Pierwsze dziesięć minut na nowym VPS dotyczy obu przypadków. Zmienia się jedynie polecenie instalacji.

Każde polecenie apt i jego odpowiednik w dnf

Instalacja, usuwanie, wyszukiwanie i wyświetlanie informacji. Polecenia te używają niemal identycznych słów w obu systemach.

# apt
sudo apt install nginx
sudo apt remove nginx
apt search nginx
apt show nginx

# dnf
sudo dnf install nginx
sudo dnf remove nginx
dnf search nginx
dnf info nginx

apt show to dnf info. Jest to jedyny zmieniony czasownik w tej grupie, jednak jedno zachowanie różni się i często zaskakuje użytkowników. dnf remove usuwa również zależności, które nie są potrzebne żadnemu innemu pakietowi, podczas gdy apt remove pozostawia je zainstalowane do późniejszego apt autoremove. Dlatego usunięcie jednego małego narzędzia w systemie Rocky Linux może skutkować propozycją usunięcia tuzina bibliotek. Przed potwierdzeniem należy przeczytać listę.

Odświeżanie metadanych, sprawdzanie oczekujących aktualizacji i aktualizacja systemu.

# apt
sudo apt update
apt list --upgradable
sudo apt install --only-upgrade nginx
sudo apt upgrade

# dnf
sudo dnf makecache
dnf check-update
sudo dnf upgrade nginx
sudo dnf upgrade

apt update jest obowiązkowe w przypadku apt, ponieważ apt korzysta z metadanych znajdujących się na dysku i bez ostrzeżenia zainstaluje wersję, która została usunięta z repozytorium miesiące temu. dnf sprawdza wiek pamięci podręcznej przed każdą transakcją i samodzielnie pobiera świeże metadane, więc sudo dnf makecache służy jedynie do wymuszenia pobrania danych w tej chwili, zamiast czekania na kolejną instalację.

apt dzieli pełną aktualizację systemu na dwa etapy, a dnf tego nie robi. apt upgrade odmawia usunięcia jakiegokolwiek zainstalowanego pakietu, więc przerywa działanie, gdy aktualizacja wymaga usunięcia zależności. apt full-upgrade to wersja, która ma uprawnienia do usuwania. dnf nie posiada takiego ograniczenia, co oznacza, że dnf upgrade jest odpowiednikiem apt full-upgrade, a nie apt upgrade. dnf update to starszy alias tego samego polecenia, który nadal działa.

Jeden szczegół jest istotny przy tworzeniu skryptów: dnf check-update kończy działanie z kodem wyjścia 100, gdy dostępne są aktualizacje, i 0, gdy ich nie ma. apt list --upgradable zawsze zwraca 0, więc skrypty muszą analizować jego wyjście.

Wyświetlanie zainstalowanych pakietów i sprawdzanie, który pakiet zawiera dany plik.

# apt
dpkg -l
dpkg -S /usr/sbin/nginx
dpkg -L nginx
apt-file search /usr/sbin/nginx

# dnf
dnf list --installed
rpm -qf /usr/sbin/nginx
rpm -ql nginx
dnf provides /usr/sbin/nginx

Ostatnia linia każdego bloku odpowiada na inne pytanie niż powyższe. dpkg -S oraz rpm -qf przeszukują tylko zainstalowane pakiety, więc odpowiadają na pytanie „co umieściło ten plik w systemie”. apt-file search oraz dnf provides przeszukują repozytoria, więc odpowiadają na pytanie „co muszę zainstalować, aby uzyskać ten plik”. apt-file jest oddzielnym pakietem w systemie Ubuntu i wymaga sudo apt-file update przed pierwszym uruchomieniem. dnf provides nie wymaga żadnych dodatkowych działań, choć pierwsze uruchomienie może być powolne, ponieważ dnf pobiera listy plików z repozytoriów, aby udzielić odpowiedzi.

Aby wyświetlić pliki wewnątrz pakietu, który nie został jeszcze zainstalowany, należy użyć dnf repoquery -l nginx. W systemie apt jest to apt-file list nginx.

Automatyczne usuwanie, czyszczenie pamięci podręcznej, blokowanie wersji.

# apt
sudo apt autoremove
sudo apt clean
sudo apt-mark hold nginx
apt-mark showhold
sudo apt-mark unhold nginx

# dnf
sudo dnf autoremove
sudo dnf clean all
sudo dnf versionlock add nginx
dnf versionlock list
sudo dnf versionlock delete nginx

versionlock nie jest domyślnie zainstalowane w systemach Rocky Linux lub AlmaLinux, więc pierwsza z tych linii zakończy się błędem No such command: versionlock na świeżo zainstalowanym systemie. Należy je najpierw zainstalować za pomocą sudo dnf install python3-dnf-plugin-versionlock. apt nie wymaga niczego dodatkowego dla apt-mark hold, ponieważ blokada (hold) jest stanem dpkg, a nie wtyczką.

Gdzie pojawia się rozbieżność: dodawanie repozytorium

To etap, na którym administratorzy Ubuntu bezskutecznie poszukują nieistniejącego polecenia. W dnf nie ma add-apt-repository, nie istnieją też personal package archives (PPA). PPA to usługa obsługiwana przez Launchpad, czyli infrastrukturę Ubuntu. W świecie RPM nie ma odpowiednika tej usługi.

Zamiast tego dnf korzysta z jednego pliku tekstowego dla każdego repozytorium w /etc/yum.repos.d/, z rozszerzeniem .repo.

[docker-ce-stable]
name=Docker CE Stable
baseurl=https://download.docker.com/linux/centos/$releasever/$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg

$releasever oraz $basearch to zmienne dnf. dnf uzupełnia numer wersji głównej oraz architekturę procesora w czasie wykonywania, dzięki czemu ten sam plik działa w wersji 9 i 10, zarówno na x86_64, jak i aarch64.

Większość dostawców publikuje taki plik i zaleca jego pobranie. Oficjalna instrukcja Docker dla RHEL i jego klonów składa się z dwóch poleceń:

sudo dnf -y install dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

Pierwsza linia jest wymagana, ponieważ config-manager to wtyczka, a nie część samego dnf. Pominięcie jej sprawia, że druga linia kończy się błędem No such command: config-manager. Nic nie stoi na przeszkodzie, aby ręcznie pobrać ten sam plik .repo za pomocą curl do /etc/yum.repos.d/; efekt będzie identyczny. Instalacja Docker na VPS opisuje analogiczne zadanie dla systemu Debian, gdzie odpowiedni krok polega na zapisaniu listy źródeł oraz klucza podpisu w dwóch różnych katalogach.

Różnica w strukturze decyduje o tym, gdzie szukać przyczyny problemów z repozytorium. apt przechowuje definicje w /etc/apt/sources.list oraz /etc/apt/sources.list.d/, a klucze podpisu oddzielnie w /etc/apt/keyrings/. dnf przechowuje wszystko w /etc/yum.repos.d/, a klucz jest adresem URL wewnątrz pliku .repo, więc wystarczy sprawdzić lub usunąć jeden plik. Nowsze wersje apt zmierzają w tym samym kierunku dzięki formatowi deb822, czyli jednemu plikowi .sources na repozytorium. Jeśli napotkano błąd zduplikowanych źródeł deb822 na Ubuntu, oznacza to, że problem ten jest już znany z perspektywy apt.

EPEL to repozytorium, które zakłada większość poradników

Extra Packages for Enterprise Linux (EPEL) to projekt społeczności Fedora, który buduje pakiety z Fedory dla RHEL oraz jego klonów. Jest to najbliższy odpowiednik uniwersalnego PPA w tym środowisku, a ogromna liczba poradników zakłada, że jest ono już włączone. Jeśli dnf install zwraca No match for argument dla pakietu, który jest widoczny na stronie projektu, EPEL jest pierwszym miejscem, które należy sprawdzić.

W systemach Rocky Linux i AlmaLinux:

sudo dnf config-manager --set-enabled crb
sudo dnf install epel-release
sudo dnf makecache

CRB to CodeReady Builder, repozytorium bibliotek dostarczane wraz z dystrybucją, które domyślnie nie jest włączone. Większość pakietów EPEL zależy od komponentów znajdujących się w tym repozytorium, więc włączenie EPEL bez CRB nie kończy się błędem w momencie konfiguracji. Błąd występuje później, podczas instalacji, w postaci nierozwiązanych zależności pakietów, o których użytkownik wcześniej nie słyszał. Włączenie CRB na początku eliminuje tę klasę błędów.

W systemie RHEL repozytorium CRB jest dostępne w ramach subskrypcji, a nie przez config-manager, dlatego w tym kroku należy postępować zgodnie z oficjalną instrukcją EPEL wydaną przez Red Hat. Fedora nie wymaga żadnych dodatkowych działań, ponieważ jej główne repozytoria zawierają już pakiety, które EPEL przenosi (backportuje). Zgodnie z polityką EPEL, repozytorium to nigdy nie zastępuje pakietów dostarczanych przez RHEL, więc dodanie go nie zmienia niczego, co jest już zainstalowane na serwerze.

dnf history undo, funkcja niedostępna w apt

dnf rejestruje każdą transakcję i potrafi wygenerować jej odwrotność.

sudo dnf history
sudo dnf history info 42
sudo dnf history undo 42

dnf history wyświetla numerowaną listę transakcji wraz z poleceniem, które je zainicjowało. undo tworzy transakcję odwrotną: pakiety zainstalowane w danej operacji zostają usunięte, a pakiety zaktualizowane wracają do poprzedniej wersji. Jest to funkcja, której użytkownicy apt najbardziej brakuje po przesiadce na dnf.

Mechanizm ten ma istotne ograniczenia, o których warto wiedzieć przed rozpoczęciem pracy. undo może przywrócić tylko taką wersję pakietu, która nadal znajduje się w aktywnym repozytorium. Gdy starsza wersja zostanie usunięta z serwera lustrzanego, operacja undo zakończy się błędem braku pakietu. Wycofanie zmian dotyczy wyłącznie bazy danych pakietów. Pliki konfiguracyjne nadpisane podczas aktualizacji pozostają w zmienionej formie, a schematy baz danych zmigrowane przez usługę przy pierwszym uruchomieniu nie wracają do poprzedniego stanu. dnf przywraca pliki, ale nie przywraca danych użytkownika.

apt nie posiada odpowiednika tej funkcji. /var/log/apt/history.log rejestruje przebieg zdarzeń, w tym użyte polecenie, jednak analiza dziennika nie jest równoznaczna z cofnięciem zmian. Odzyskiwanie w apt odbywa się ręcznie: należy użyć apt list -a nginx, aby sprawdzić, jakie wersje są jeszcze dostępne w archiwum, następnie sudo apt install nginx=<exact version string>, aby przypiąć wybraną wersję, oraz dodać sudo apt-mark hold nginx, aby kolejna aktualizacja nie nadpisała wprowadzonej poprawki.

Grupy pakietów nie mają odpowiednika w apt

Narzędzie dnf pozwala na instalację nazwanego zestawu pakietów za pomocą jednego polecenia.

dnf group list
dnf group info "Development Tools"
sudo dnf group install "Development Tools"

Starsze poradniki wspominają o dnf groupinstall "Development Tools". Ten alias działa w dnf 4, ale został usunięty w dnf 5, dlatego dwuwyrazowe dnf group install jest jedyną formą zapisu działającą w każdym środowisku. Należy stosować tę formę i nie korzystać z innych.

System apt nie posiada grup. Najbliższym odpowiednikiem w Debianie jest metapakiet, czyli pusty pakiet, którego jedyną zawartością jest lista zależności, na przykład build-essential. Różnica w praktyce jest istotna: usunięcie metapakietu pozostawia jego zależności w systemie do momentu uruchomienia apt autoremove, podczas gdy dnf group remove usuwa pakiety należące do grupy w ramach tej samej transakcji.

unattended-upgrades oraz dnf-automatic

Obie rodziny narzędzi oferują sposób na instalację aktualizacji bez konieczności logowania użytkownika. Narzędzia te nie mają ze sobą nic wspólnego poza celem działania.

W systemach Ubuntu i Debian pakietem jest unattended-upgrades, konfigurowany w /etc/apt/apt.conf.d/50unattended-upgrades, gdzie należy wymienić źródła, z których pobieranie jest dozwolone. Konfiguracja unattended-upgrades w systemie Ubuntu omawia ten plik konfiguracyjny oraz kwestię restartów, która się z nim wiąże.

W systemach Rocky Linux, AlmaLinux oraz Fedora pakietem jest dnf-automatic, a o zachowaniu decyduje włączony timer systemd.

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic-install.timer
systemctl list-timers 'dnf-automatic*'

dnf-automatic-install.timer pobiera i instaluje aktualizacje. dnf-automatic-download.timer jedynie je pobiera i kończy działanie, pozostawiając instalację użytkownikowi. dnf-automatic-notifyonly.timer jedynie raportuje stan. Każda z tych jednostek nadpisuje ustawienie apply_updates w pliku /etc/dnf/automatic.conf, dlatego wybór timera jest ważniejszy niż zawartość pliku konfiguracyjnego.

Aby ograniczyć działanie wyłącznie do poprawek bezpieczeństwa, należy ustawić upgrade_type = security w /etc/dnf/automatic.conf. Ten filtr zależy od tego, czy repozytoria publikują erraty bezpieczeństwa, dlatego należy to najpierw sprawdzić za pomocą dnf updateinfo list security. Pusty wynik na maszynie z oczekującymi aktualizacjami oznacza brak odpowiednich metadanych, przez co security nie zainstaluje żadnych pakietów.

W systemie Fedora narzędzie dnf 5 zmieniło nazwę jednostki. Jest to dnf5-automatic.timer, która odczytuje ten sam plik /etc/dnf/automatic.conf.

Czy yum jest nadal rzeczywistym poleceniem?

Tak, choć samodzielnie nie wykonuje żadnych operacji. W systemach Rocky Linux, AlmaLinux oraz CentOS Stream, /usr/bin/yum jest dowiązaniem symbolicznym wskazującym na dnf. Można to zweryfikować poleceniem:

ls -l /usr/bin/yum
dnf --version

Stara składnia yum wciąż pojawia się w poradnikach, ponieważ większość jej elementów jest bezpośrednio obsługiwana. yum install, yum remove oraz yum update działają poprawnie. Warto jednak porzucić jeden nawyk: yum-config-manager nadal istnieje jako osobny plik binarny w systemach z dnf 4, jednak dnf config-manager jest zapisem stosowanym w aktualnej dokumentacji i to on będzie działał po migracji systemu do dnf 5.

dnf 4 oraz dnf 5: sprawdź przed skopiowaniem polecenia

dnf 5 to całkowicie przepisana wersja, w której zmieniono składnię wielu poleceń. Fedora 41 i nowsze wersje dostarczają go jako dnf. Dystrybucje typu enterprise rebuild przechodzą na tę wersję wolniej, dlatego nie należy zgadywać na podstawie nazwy systemu. Uruchom dnf --version na własnym serwerze i odczytaj pierwszą linię, ponieważ ten numer decyduje o tym, której składni z poniższych należy użyć.

Najlepszym przykładem jest Docker, który publikuje inne polecenie dodawania repozytorium dla każdej z wersji. W systemie RHEL i jego odpowiednikach, z dnf 4:

sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

W systemie Fedora, z dnf 5:

sudo dnf config-manager addrepo --from-repofile https://download.docker.com/linux/fedora/docker-ce.repo

Ten sam dostawca, to samo zadanie, inne słowa. dnf 5 zmienił config-manager w narzędzie oparte na podpoleceniach, więc stara flaga --add-repo nie jest akceptowana, co skutkuje błędem użycia zamiast dodaniem repozytorium. Kolejną różnicą, z którą się zetkniesz, jest włączanie repozytorium: dnf config-manager --set-enabled crb w dnf 4 zmienia się w dnf config-manager setopt crb.enabled=1 w dnf 5.

Wybór, który ma rzeczywiste znaczenie

Wybieranie dystrybucji serwerowej wyłącznie na podstawie menedżera pakietów jest błędnym podejściem. dnf oraz apt wykonują tę samą pracę, a opanowanie ich składni zajmuje jedno popołudnie. Tym, co wpływa na całoroczną pracę, jest model wydawniczy repozytorium. Fedora rozwija się szybko, a wsparcie dla danego wydania kończy się mniej więcej trzynaście miesięcy po jego publikacji, co jest akceptowalne dla stacji roboczej, lecz uciążliwe w przypadku serwera, którego nie chcemy przebudowywać. Rocky Linux i AlmaLinux podążają za RHEL, dzięki czemu otrzymujemy dziesięcioletni okres wsparcia oraz wersje pakietów, które celowo pozostają niezmienione. Ubuntu oferuje oba warianty, a różnica między Ubuntu LTS a wydaniami tymczasowymi na serwerze stanowi tę samą decyzję, którą podejmuje się w świecie apt.

Według stanu na sierpień 2026 roku, wszystkie wymienione systemy są standardowymi obrazami VPS. Należy wybrać pożądany okres wsparcia, a następnie opanować dziesięć powyższych poleceń.

FAQ

Jaki jest odpowiednik polecenia apt update w dnf?

Nie ma polecenia, które trzeba uruchamiać ręcznie. dnf sprawdza wiek metadanych w pamięci podręcznej przed każdą transakcją i pobiera świeżą kopię, gdy wygaśnie, więc dnf install na serwerze, który nie był używany przez miesiąc, nadal widzi aktualne pakiety. sudo dnf makecache istnieje i wymusza pobranie, ale jego rzeczywistym zastosowaniem jest przesunięcie opóźnienia na wybrany czas, zamiast uwzględniania go przy następnej instalacji. Poleceniem, które odpowiada na pytanie „co czeka na aktualizację”, jest dnf check-update, które mapuje się na apt list --upgradable i kończy działanie z kodem wyjścia 100, gdy dostępne są aktualizacje.

Czy istnieje odpowiednik PPA w systemach Rocky Linux lub Fedora?

Nie. Personal package archives to usługa platformy Launchpad, która jest infrastrukturą Ubuntu, więc add-apt-repository nie ma odpowiednika. Odpowiednikiem w formacie RPM jest plik .repo w katalogu /etc/yum.repos.d/, zawierający nazwę, baseurl oraz gpgkey. Dostawcy publikują taki plik, a sudo dnf config-manager --add-repo <url> w dnf 4 lub sudo dnf config-manager addrepo --from-repofile <url> w dnf 5 pobiera go i umieszcza w odpowiednim miejscu. W przypadku ogólnego dodatkowego oprogramowania odpowiedzią jest zazwyczaj EPEL, który włącza się za pomocą sudo dnf config-manager --set-enabled crb, a następnie sudo dnf install epel-release.

Czy można cofnąć aktualizację dnf, która uszkodziła serwer?

Tak, w określonych granicach. Należy uruchomić sudo dnf history, aby znaleźć numer transakcji, sudo dnf history info <id>, aby zobaczyć dokładnie, co zostało zmienione, a następnie sudo dnf history undo <id>. Operacja cofnięcia nie powiedzie się, jeśli starsza wersja pakietu nie jest już dostępna w żadnym włączonym repozytorium, ponieważ dnf nie ma skąd dokonać ponownej instalacji. Polecenie to cofa tylko zmiany w pakietach. Plik konfiguracyjny nadpisany przez aktualizację lub baza danych zmigrowana przez usługę przy pierwszym uruchomieniu pozostają w zmienionym stanie. apt nie posiada żadnego odpowiednika tego polecenia, jedynie zapis w /var/log/apt/history.log.

Czy yum nadal działa w systemach Rocky Linux i AlmaLinux?

Działa, ponieważ /usr/bin/yum jest dowiązaniem symbolicznym do dnf. Można to potwierdzić na własnym systemie za pomocą ls -l /usr/bin/yum. Wpisanie yum install httpd uruchamia dnf, więc stare poradniki w większości nadal działają. Nowe skrypty i dokumentację należy tworzyć z użyciem dnf, ponieważ nazwa yum służy wyłącznie zachowaniu kompatybilności; należy również preferować dnf config-manager zamiast starszego pliku binarnego yum-config-manager.

Dlaczego dnf remove chce usunąć tak wiele pakietów?

Ponieważ dnf usuwa zależności, które nie są potrzebne żadnemu innemu pakietowi w ramach tej samej transakcji, podczas gdy apt remove pozostawia je zainstalowane do momentu osobnego uruchomienia apt autoremove. Dlatego usunięcie, które na Ubuntu wydaje się niewielkie, na Rocky Linux może wyświetlić długą listę. Lista jest zazwyczaj poprawna, ale należy ją przeczytać przed potwierdzeniem. Jeśli na liście znajduje się pakiet, który ma zostać zachowany, należy go najpierw zainstalować jawnie, aby dnf zarejestrował go jako wymagany samodzielnie.