apt і dnf: відповідники команд для Rocky та Fedora

Коротка відповідь

Перехід з apt на dnf здебільшого означає зміну термінології. apt install nginx стає dnf install nginx. apt remove nginx стає dnf remove nginx. apt update не має прямого відповідника, оскільки dnf сам оновлює метадані репозиторіїв, коли кешована копія застаріває. Простий бік такого переходу займає один екран. Практично важливий бік — це чотири операції, які взагалі не мають прямого відповідника: додавання репозиторію, скасування транзакції, встановлення групи пакетів і запуск автоматичних оновлень.

Наведені нижче команди призначені для виконання на вашому сервері. Перед відповіддю на y прочитайте підсумок транзакції, який виводить dnf, особливо якщо йдеться про видалення пакетів.

Які дистрибутиви використовують dnf, а які — apt

dnf — це менеджер пакунків у Fedora, Red Hat Enterprise Linux (RHEL) і дистрибутивах на основі RHEL: Rocky Linux, AlmaLinux та CentOS Stream. apt — це менеджер пакунків у Debian і всіх дистрибутивах на основі Debian, що на VPS майже завжди означає Ubuntu. Третього варіанта немає. Якщо у списку образів вашого провайдера є Rocky Linux або AlmaLinux, ви отримуєте dnf. Якщо там є Ubuntu, ви отримуєте apt.

Формат пакунків відповідає інструменту. dnf встановлює файли .rpm, а його база даних має формат rpm. apt встановлює файли .deb, а його база даних має формат dpkg. Саме тому на сторінках встановлення багатьох постачальників є окрема вкладка для кожного сімейства, а файл .deb, завантажений зі сторінки релізу проєкту, марний у Rocky Linux.

Незалежно від вибраного сімейства, перший вхід виконується однаково. Перші десять хвилин на новому VPS стосуються обох варіантів. Змінюється лише команда встановлення.

Кожна команда apt та її еквівалент у dnf

Встановлення, видалення, пошук і перегляд інформації. В обох випадках використовуються майже однакові слова.

# 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 — це dnf info. Це єдина перейменована дієслівна команда в цій групі, але одна відмінність у поведінці часто спричиняє помилки. dnf remove також видаляє залежності, які більше нічому не потрібні, а apt remove залишає їх встановленими для подальшого apt autoremove. Тому під час видалення невеликої утиліти в Rocky Linux може бути запропоновано видалити разом із нею десяток бібліотек. Перед підтвердженням перегляньте список.

Оновлення метаданих, перевірка очікуваних оновлень і оновлення системи.

# 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 є обов’язковою командою в apt, оскільки apt використовує метадані, збережені на диску, і без проблем може встановити версію, яка вийшла з архіву кілька місяців тому. Перед кожною транзакцією dnf перевіряє вік свого кешу та самостійно завантажує актуальні метадані, тому sudo dnf makecache потрібна лише для примусового завантаження метаданих зараз, а не під час наступного встановлення.

apt розділяє повне оновлення системи на два етапи, а dnf — ні. apt upgrade відмовляється видаляти будь-який встановлений пакет, тому зупиняється, коли оновлення потребує видалення пакета. apt full-upgrade — це версія, якій дозволено видаляти пакети. У dnf такого обмеження немає, тому dnf upgrade є еквівалентом apt full-upgrade, а не apt upgrade. dnf update — старий псевдонім тієї самої команди, який досі працює.

Якщо ви використовуєте ці команди у скрипті, важлива одна деталь: dnf check-update завершується зі статусом 100, коли доступні оновлення, і зі статусом 0, коли їх немає. apt list --upgradable у будь-якому випадку завершується зі статусом 0, тому скрипти мають аналізувати її вивід.

Перелік встановлених пакетів і визначення пакета, якому належить файл.

# 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

Останній рядок кожного блоку відповідає на інше запитання, ніж попередні рядки. dpkg -S і rpm -qf шукають лише серед уже встановлених пакетів, тому відповідають на запитання «що встановило цей файл». apt-file search і dnf provides шукають у репозиторіях, тому відповідають на запитання «що потрібно встановити, щоб отримати цей файл». apt-file є окремим пакетом в Ubuntu, і перед першим запуском потребує sudo apt-file update. dnf provides не потребує нічого додаткового, хоча перший запуск може бути повільним, оскільки dnf завантажує списки файлів із репозиторіїв для виконання пошуку.

Щоб переглянути файли в пакеті, який ще не встановлено, використовуйте dnf repoquery -l nginx. В apt для цього використовується apt-file list nginx.

Автоматичне видалення, очищення кешу та фіксація версії.

# 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 не встановлено за замовчуванням у Rocky Linux або AlmaLinux, тому перший із цих рядків на чистій системі завершується помилкою No such command: versionlock. Спочатку встановіть його за допомогою sudo dnf install python3-dnf-plugin-versionlock. Для apt-mark hold apt не потребує нічого додаткового, оскільки фіксація версії є станом dpkg, а не плагіном.

Де аналогія перестає працювати: додавання репозиторію

Саме на цьому етапі адміністратори Ubuntu починають шукати команду, якої не існує. У dnf немає add-apt-repository, а персональних архівів пакетів (PPA) також немає. PPA — це сервіс, який працює на Launchpad, а Launchpad є інфраструктурою Ubuntu. У світі RPM немає сервісу, який розміщує такі архіви.

Натомість dnf використовує по одному звичайному текстовому файлу для кожного репозиторію в /etc/yum.repos.d/. Назва файлу має закінчуватися на .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 і $basearch — це змінні dnf. Під час виконання dnf підставляє номер основного випуску та архітектуру CPU. Тому один і той самий файл працює у версіях 9 і 10, а також на x86_64 та aarch64.

Більшість постачальників публікують цей файл і вказують, як його завантажити. Власні інструкції Docker для RHEL та його сумісних дистрибутивів складаються з двох команд:

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

Перший рядок потрібен тому, що config-manager є плагіном, а не частиною самого dnf. Якщо пропустити цей рядок, друга команда завершиться помилкою No such command: config-manager. Ніщо не заважає вручну завантажити той самий файл .repo за допомогою curl до /etc/yum.repos.d/. Результат буде ідентичним. У матеріалі Встановлення Docker на VPS описано аналогічний крок для Debian: там список джерел і ключ підпису записуються у два різні каталоги.

Відмінності в структурі визначають, де шукати проблему, якщо репозиторій працює неправильно. apt зберігає визначення в /etc/apt/sources.list і /etc/apt/sources.list.d/, а ключі підпису — окремо в /etc/apt/keyrings/. dnf зберігає все в /etc/yum.repos.d/, а ключ міститься як URL усередині файлу .repo. Тому потрібно прочитати один файл і видалити один файл. У новіших версіях apt використовується подібна структура у форматі deb822: для кожного репозиторію створюється один файл .sources. Якщо ви вже стикалися з помилкою дубльованих джерел deb822 в Ubuntu, то вже бачили частину цієї проблеми, пов’язану з apt.

EPEL — це репозиторій, який передбачає більшість інструкцій

Extra Packages for Enterprise Linux (EPEL) — це проєкт Fedora, який збирає пакети Fedora для RHEL і його сумісних збірок. Це найближчий аналог універсального PPA, який існує в цій екосистемі, тому дуже багато інструкцій передбачають, що його вже увімкнено. Якщо dnf install відповідає No match for argument для пакета, який зазначено на офіційному вебсайті проєкту, спочатку перевірте EPEL.

У Rocky Linux і AlmaLinux:

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

CRB — це CodeReady Builder, репозиторій бібліотек, який постачається з дистрибутивом, але за замовчуванням не увімкнений. Більшість пакетів EPEL залежать від пакетів із нього, тому ввімкнення EPEL без CRB не спричиняє помилки одразу. Помилка виникає пізніше, під час встановлення, через нерозв’язані залежності від пакета, про який ви ніколи не чули. Спочатку увімкніть CRB — це усуне такий клас помилок.

У самому RHEL CRB надається через вашу підписку, а не через config-manager, тому для цього кроку скористайтеся офіційними інструкціями Red Hat щодо EPEL. Fedora цього не потребує, оскільки її основний репозиторій уже містить пакети, які EPEL переносить із новіших версій. Політика EPEL забороняє замінювати пакети, які постачає RHEL, тому додавання репозиторію не змінює нічого з уже встановленого на сервері.

dnf history undo, функція, якої немає в apt

dnf записує кожну транзакцію та може сформувати зворотну транзакцію для неї.

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

dnf history виводить нумерований список транзакцій із командним рядком, який запустив кожну з них. undo формує зворотну транзакцію: пакети, установлені цією транзакцією, видаляються, а пакети, оновлені нею, повертаються до попередньої версії. Саме цієї функції найбільше бракує користувачам apt після переходу.

Функція має суттєві обмеження, про які варто знати до її використання. undo може повторно встановити версію пакета лише тоді, коли ця версія все ще доступна в увімкненому репозиторії. Якщо стару збірку вже видалено із дзеркала, скасування завершиться помилкою про відсутній пакет. Відкат також зупиняється на рівні бази даних пакетів. Файл конфігурації, який перезаписало оновлення, залишиться перезаписаним, а схема бази даних, яку сервіс змінив під час першого запуску, залишиться зміненою. dnf повертає файли. Воно не відновлює ваші дані.

В apt немає еквівалентної функції. /var/log/apt/history.log точно записує, що сталося, зокрема командний рядок, але читання журналу не скасовує виконані дії. Відновлення на стороні apt виконується вручну: виконайте apt list -a nginx, щоб перевірити, які версії ще доступні в архіві, потім sudo apt install nginx=<exact version string>, щоб зафіксувати потрібну версію, і додайте sudo apt-mark hold nginx, щоб наступне оновлення не скасувало це виправлення.

Групи пакунків не мають еквівалента в apt

dnf може встановити іменований набір пакунків однією командою.

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

У старих посібниках використовується dnf groupinstall "Development Tools". Цей псевдонім працює в dnf 4 і відсутній у dnf 5, тому двослівна форма dnf group install — єдиний варіант, який працює всюди. Використовуйте її й більше про це не думайте.

В apt немає груп. Найближче поняття в Debian — метапакунок: фактично порожній пакунок, єдиним вмістом якого є список залежностей, наприклад build-essential. Практична різниця проявляється під час видалення: після видалення метапакунка його залежності залишаються встановленими, доки ви не виконаєте apt autoremove, тоді як dnf group remove видаляє пакунки групи в межах тієї самої транзакції.

автоматичні оновлення та dnf-automatic

Обидві родини інструментів дають змогу встановлювати оновлення, навіть коли ніхто не ввійшов у систему. Вони мають спільне лише призначення.

В Ubuntu і Debian пакет має назву unattended-upgrades, а його налаштовують у /etc/apt/apt.conf.d/50unattended-upgrades. У цьому файлі вказують джерела, з яких дозволено отримувати оновлення. У матеріалі Налаштування unattended upgrades в Ubuntu описано цей файл конфігурації та питання перезавантаження, яке з ним пов’язане.

У Rocky Linux, AlmaLinux і Fedora пакет має назву dnf-automatic. Увімкнений таймер systemd визначає його поведінку.

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

dnf-automatic-install.timer завантажує та встановлює оновлення. dnf-automatic-download.timer завантажує їх і зупиняється, залишаючи встановлення вам. dnf-automatic-notifyonly.timer лише формує звіт. Кожен із цих unit-файлів перевизначає параметр apply_updates у /etc/dnf/automatic.conf, тому вибраний таймер важливіший за значення у файлі конфігурації.

Щоб обмежити оновлення лише виправленнями безпеки, задайте upgrade_type = security у /etc/dnf/automatic.conf. Цей фільтр залежить від того, чи публікують ваші репозиторії security errata, тому спочатку перевірте це за допомогою dnf updateinfo list security. Порожній результат на сервері, для якого доступні оновлення, означає, що в метаданих немає відповідної інформації. У такому разі security взагалі нічого не встановить.

У Fedora dnf 5 перейменував unit-файл. Тепер це dnf5-automatic.timer, і він читає той самий /etc/dnf/automatic.conf.

Чи є yum справжньою командою?

Так. Однак сама по собі вона нічого не робить. У Rocky Linux, AlmaLinux і CentOS Stream /usr/bin/yum — це символічне посилання на dnf. Перевірте це у своїй системі:

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

Синтаксис yum часто трапляється в навчальних матеріалах, оскільки більшість його конструкцій і далі безпосередньо передається до dnf. Працюють і yum install, yum remove та yum update. Від однієї звички варто відмовитися: yum-config-manager досі існує як окремий двійковий файл у системах із dnf 4, але dnf config-manager — це варіант написання, який використовує актуальна документація. Саме він продовжує працювати після переходу системи на dnf 5.

dnf 4 і dnf 5: перевірте версію, перш ніж копіювати команду

dnf 5 — це переписана версія, у якій змінилося написання кількох команд. У Fedora 41 і новіших версіях він постачається як dnf. Корпоративні збірки переходили на нього повільніше, тому не визначайте версію лише за назвою дистрибутива. Виконайте dnf --version на власному сервері та прочитайте перший рядок, оскільки саме цей номер визначає, який синтаксис нижче потрібно використовувати.

Найнаочніший приклад — Docker, який публікує окрему команду для підключення репозиторію для кожної версії. У RHEL і його збірках, з dnf 4:

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

У Fedora, з dnf 5:

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

Той самий постачальник, те саме завдання, але інший синтаксис. У dnf 5 config-manager перетворено на інструмент із командами-підкомандами, тому старий прапорець --add-repo не приймається, і замість репозиторію ви отримуєте помилку використання. Інша команда, з якою ви можете зіткнутися, — увімкнення репозиторію: dnf config-manager --set-enabled crb у dnf 4 відповідає dnf config-manager setopt crb.enabled=1 у dnf 5.

Вибір, який справді має значення

Вибирати дистрибутив сервера лише за менеджером пакетів — неправильний критерій. dnf і apt виконують ту саму роботу, а їхню термінологію можна опанувати за один день. На ваш рік роботи впливає модель випуску, на якій ґрунтується репозиторій. Fedora швидко розвивається, а окремий випуск припиняє отримувати оновлення приблизно через тринадцять місяців після виходу. Для робочої станції це прийнятно, але для сервера, який не потрібно перебудовувати, це створює проблеми. Rocky Linux і AlmaLinux орієнтуються на RHEL, тому ви отримуєте десятирічний період підтримки та версії пакетів, які навмисно залишаються стабільними. Ubuntu пропонує обидва варіанти, і різниця між Ubuntu LTS і проміжними випусками Ubuntu на сервері — це те саме рішення у світі apt.

Станом на August 2026 усі ці дистрибутиви є звичайними образами VPS. Виберіть потрібний період підтримки, а потім вивчіть десять наведених вище команд.

FAQ

Який еквівалент apt update у dnf?

Немає команди, яку потрібно виконувати. Перед кожною транзакцією dnf перевіряє, наскільки застаріли його кешовані метадані, і завантажує свіжу копію, якщо термін її дії минув. Тому dnf install на сервері, до якого ви не зверталися протягом місяця, усе одно бачить актуальні пакети. Команда sudo dnf makecache існує та справді примусово завантажує ці метадані, але її основне призначення — перенести затримку на вибраний вами час, а не чекати її під час наступного встановлення. Команда, яка відповідає на запитання «що на мене чекає», — це dnf check-update. Вона відповідає apt list --upgradable і завершується зі статусом 100, якщо доступні оновлення.

Чи є еквівалент PPA у Rocky Linux або Fedora?

Ні. Персональні архіви пакетів є сервісом Launchpad, а Launchpad належить до інфраструктури Ubuntu, тому add-apt-repository не має прямого еквівалента. Еквівалентом у світі RPM є файл .repo у каталозі /etc/yum.repos.d/. Він містить назву, baseurl і gpgkey. Постачальники публікують цей файл, а sudo dnf config-manager --add-repo <url> у dnf 4 або sudo dnf config-manager addrepo --from-repofile <url> у dnf 5 завантажує його на потрібне місце. Для додаткового програмного забезпечення загального призначення зазвичай використовують EPEL. Його вмикають за допомогою sudo dnf config-manager --set-enabled crb, а потім sudo dnf install epel-release.

Чи можна скасувати оновлення dnf, через яке сервер перестав працювати?

Так, але з певними обмеженнями. Виконайте sudo dnf history, щоб знайти номер транзакції, sudo dnf history info <id>, щоб точно побачити її зміни, а потім sudo dnf history undo <id>. Скасування не спрацює, якщо старішої версії пакета вже немає в жодному ввімкненому репозиторії, оскільки dnf не має звідки її повторно встановити. Крім того, ця операція скасовує лише зміни пакетів. Файл конфігурації, переписаний під час оновлення, або база даних, мігрована сервісом під час першого запуску, залишаються без змін. В apt взагалі немає еквівалентної команди — є лише запис у /var/log/apt/history.log.

Чи працює yum у Rocky Linux та AlmaLinux?

Він працює, оскільки /usr/bin/yum є символічним посиланням на dnf. Перевірте це у своїй системі за допомогою ls -l /usr/bin/yum. Виконання yum install httpd запускає dnf, тому старі посібники здебільшого й надалі працюють. У нових скриптах і документації використовуйте dnf, оскільки назва yum потрібна лише для сумісності. Також надавайте перевагу dnf config-manager замість старішого бінарного файла yum-config-manager.

Чому dnf remove хоче видалити так багато пакетів?

Тому що dnf у межах тієї самої транзакції видаляє залежності, які більше нічому не потрібні, тоді як apt remove залишає їх установленими, доки ви окремо не виконаєте apt autoremove. Через це невелике видалення в Ubuntu може вивести довгий список у Rocky Linux. Зазвичай цей список правильний, але перегляньте його перед підтвердженням. Якщо в ньому є пакет, який ви хочете зберегти, спочатку встановіть його явно. Тоді dnf позначить його як пакет, потрібний безпосередньо користувачу.