Odpowiedniki poleceń apt w dnf dla Rocky Linux i Fedora

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ęść użyteczna obejmuje cztery operacje, które nie mają bezpośrednich odpowiedników: dodawanie repozytorium, wycofywanie transakcji, instalację grup 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 przeczytać podsumowanie transakcji wyświetlone 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 oferuje Rocky Linux lub AlmaLinux, otrzymuje się dnf. Jeśli oferuje Ubuntu, otrzymuje się apt. Powód, dla którego jedna strona tego podziału posiada cztery nazwy dla w dużej mierze tego samego systemu, jest historią, którą warto poznać przed dokonaniem wyboru, a jak Red Hat Linux stał się Fedora, RHEL, CentOS, Rocky i AlmaLinux wyjaśnia pochodzenie każdego z nich.

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 producentów posiada osobne zakładki dla każdej rodziny 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 kilkunastu 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 wahania zainstaluje wersję, która została usunięta z repozytorium wiele miesięcy 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 podczas następnej instalacji.

apt dzieli pełną aktualizację systemu na dwa etapy, natomiast 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ół ma znaczenie 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 dostarcza 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

Ostatni wiersz każdego bloku odpowiada na inne pytanie niż poprzednie. dpkg -S oraz rpm -qf przeszukują tylko zainstalowane pakiety, odpowiadając na pytanie „co umieściło ten plik w systemie”. apt-file search oraz dnf provides przeszukują repozytoria, odpowiadając 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 w celu udzielenia odpowiedzi.

Aby wyświetlić listę plików 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 pakietu.

# 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 ani AlmaLinux, więc pierwsze z tych poleceń 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 do apt-mark hold, ponieważ blokada (hold) jest stanem dpkg, a nie wtyczką.

Gdzie pojawiają się problemy z mapowaniem: dodawanie repozytorium

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

Zamiast tego dnf wykorzystuje jeden plik tekstowy 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 systemów pochodnych 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 spowoduje, że druga linia zakoń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 ten sam proces 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 plików 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, gdzie dla każdego repozytorium przypada jeden plik .sources. Jeśli wystąpił błąd duplikacji źródeł deb822 w Ubuntu, oznacza to, że problem ten został już napotkany w środowisku 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 dostarcza 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 jest wyłączone. Większość pakietów EPEL zależy od komponentów w nim zawartych, więc włączenie EPEL bez CRB nie powoduje błędu w tym momencie. Błąd występuje później, podczas instalacji, w postaci nierozwiązanych zależności od pakietu, o którym użytkownik nigdy nie słyszał. Włączenie CRB w pierwszej kolejności 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 z tych działań, ponieważ jej główne repozytorium zawiera już pakiety, które EPEL przenosi (backportuje). Zasadą EPEL jest nigdy nie zastępować pakietów dostarczanych przez RHEL, więc dodanie tego repozytorium 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 linią poleceń, która je zainicjowała. undo tworzy transakcję przeciwną: 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 zmianie menedżera pakietów.

Rozwiązanie to posiada realne ograniczenia, o których warto wiedzieć przed poleganiem na nim. undo może przywrócić wersję pakietu tylko wtedy, gdy nadal istnieje ona w włączonym repozytorium. Gdy starsza wersja zostanie usunięta z serwera lustrzanego, operacja undo kończy się błędem not-found. Wycofanie zmian dotyczy wyłącznie bazy danych pakietów. Plik konfiguracyjny nadpisany podczas aktualizacji pozostaje w nowej formie, a schemat bazy danych zmigrowany przez usługę przy pierwszym uruchomieniu nie wraca do poprzedniego stanu. dnf przywraca pliki, ale nie przywraca danych użytkownika.

apt nie posiada odpowiednika tej funkcji. /var/log/apt/history.log rejestruje dokładnie przebieg zdarzeń, w tym linię poleceń, jednak odczyt dziennika nie jest równoznaczny z cofnięciem zmian. Odzyskiwanie w środowisku apt jest procesem ręcznym: należy uruchomić apt list -a nginx, aby sprawdzić, jakie wersje są dostępne w archiwum, następnie użyć sudo apt install nginx=<exact version string> w celu przypięcia wersji i 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 umożliwia 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 używają dnf groupinstall "Development Tools". Ten alias działa w dnf 4, lecz został usunięty w dnf 5, dlatego dwuwyrazowe dnf group install jest jedyną formą działającą wszędzie. Należy jej używać i nie poświęcać temu więcej uwagi.

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 tej samej transakcji.

unattended-upgrades oraz dnf-automatic

Obie rodziny systemów oferują mechanizmy instalacji aktualizacji bez konieczności logowania użytkownika. Narzędzia te łączy jedynie cel, a nie implementacja.

W systemach Ubuntu i Debian pakietem jest unattended-upgrades, konfigurowany w /etc/apt/apt.conf.d/50unattended-upgrades, gdzie definiuje się dozwolone źródła aktualizacji. Konfiguracja unattended-upgrades w systemie Ubuntu omawia ten plik konfiguracyjny oraz kwestię automatycznego restartu.

W systemach Rocky Linux, AlmaLinux i Fedora pakietem jest dnf-automatic, a o zachowaniu systemu 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 pobiera pakiety i kończy działanie, pozostawiając instalację użytkownikowi. dnf-automatic-notifyonly.timer służy wyłącznie do raportowania. 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. Instalacja aktualizacji nie restartuje procesów korzystających ze starego kodu, dlatego przed założeniem, że system jest w pełni zabezpieczony, warto sprawdzić które aktualizacje wymagają restartu systemu, a które jedynie restartu usług.

Aby ograniczyć działanie narzędzia wyłącznie do poprawek bezpieczeństwa, należy ustawić upgrade_type = security w pliku /etc/dnf/automatic.conf. Ten filtr zależy od tego, czy repozytoria publikują erraty bezpieczeństwa, co można zweryfikować za pomocą dnf updateinfo list security. Pusty wynik na systemie 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 korzysta z tego samego pliku /etc/dnf/automatic.conf.

Czy yum jest nadal rzeczywistym poleceniem?

Tak, jednak samo w sobie nie wykonuje żadnych operacji. W systemach Rocky Linux, AlmaLinux oraz CentOS Stream, /usr/bin/yum jest dowiązaniem symbolicznym wskazującym na dnf. Należy sprawdzić własną konfigurację:

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

Stara składnia yum nadal pojawia się w poradnikach, ponieważ większość poleceń jest przekazywana bezpośrednio. 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, ale dnf config-manager jest zapisem stosowanym w bieżącej 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 przepisana wersja narzędzia, w której zmieniono składnię kilku poleceń. Fedora 41 i nowsze wersje dostarczają je jako dnf. Dystrybucje typu enterprise rebuild przechodzą na nie wolniej, dlatego nie należy zgadywać na podstawie nazwy systemu. Uruchom dnf --version na własnym serwerze i przeczytaj pierwszą linię, ponieważ to ona decyduje, której składni poniżej 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 przekształciło 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ą zmianą, z którą się zetkniesz, jest włączanie repozytorium: dnf config-manager --set-enabled crb w dnf 4 staje się dnf config-manager setopt crb.enabled=1 w dnf 5.

Wybór, który ma znaczenie

Wybór 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. O tym, jak będzie wyglądał rok pracy, decyduje model wydawniczy repozytorium. Fedora rozwija się szybko, a wsparcie dla danego wydania kończy się mniej więcej trzynaście miesięcy po jego premierze, co jest akceptowalne na 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 sprowadza się do tej samej decyzji podejmowanej wewnątrz ekosystemu apt.

Według stanu na sierpień 2026, 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. Przed każdą transakcją dnf sprawdza wiek metadanych w pamięci podręcznej i pobiera ich świeżą kopię, jeśli wygasły. Dzięki temu dnf install na serwerze, na którym nie wykonywano żadnych operacji przez miesiąc, nadal widzi aktualne pakiety. Polecenie sudo dnf makecache istnieje i wymusza pobranie, ale jego rzeczywistym zastosowaniem jest przesunięcie czasu oczekiwania na moment wybrany przez administratora, zamiast doliczania go do kolejnej 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. Archiwa pakietów osobistych (PPA) to usługa platformy Launchpad, która jest infrastrukturą systemu Ubuntu, więc add-apt-repository nie ma odpowiednika. Odpowiednikiem w świecie RPM jest plik .repo w katalogu /etc/yum.repos.d/, zawierający nazwę, baseurl oraz gpgkey. Dostawcy udostępniają 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 rozwiązaniem 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 sprawdzić, co dokładnie zostało zmienione, a następnie sudo dnf history undo <id>. Cofnięcie nie powiedzie się, jeśli starsza wersja pakietu nie jest już dostępna w żadnym włączonym repozytorium, ponieważ dnf nie ma skąd ponownie zainstalować plików. Operacja ta 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, a 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 serwerze za pomocą ls -l /usr/bin/yum. Wpisanie yum install httpd uruchamia dnf, więc większość starych poradników nadal jest użyteczna. Nowe skrypty i dokumentację należy tworzyć z użyciem dnf, ponieważ nazwa yum służy wyłącznie zachowaniu kompatybilności. Należy 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ą już potrzebne żadnemu innemu pakietowi w ramach tej samej transakcji, podczas gdy apt remove pozostawia je zainstalowane do czasu ręcznego uruchomienia apt autoremove. Dlatego usunięcie, które w systemie Ubuntu wygląda na niewielkie, w systemie Rocky Linux może wygenerować długą listę. Lista ta 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 niezależnie.