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. Чому одна сторона цього поділу має чотири назви для майже тієї самої системи — це історія, яку варто знати перед вибором між ними. У статті Як Red Hat Linux перетворився на Fedora, RHEL, CentOS, Rocky та AlmaLinux пояснюється походження кожного з них.

Формат пакета залежить від інструмента. 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 видаляє пакети групи разом із нею в межах тієї самої транзакції.

unattended-upgrades і dnf-automatic

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

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

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

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, тому вибраний timer важливіший за значення в конфігураційному файлі. Встановлення оновлення не перезапускає процеси, які все ще виконують старий код. Тому перед тим, як вважати сервер оновленим, варто перевірити, для яких із цих оновлень потрібне перезавантаження, а для яких достатньо перезапустити сервіс.

Щоб обмежити оновлення лише виправленнями безпеки, задайте 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. Корпоративні rebuild-дистрибутиви переходили на нього повільніше, тому не визначайте версію за назвою дистрибутива. Виконайте dnf --version на власному сервері та прочитайте перший рядок, оскільки саме цей номер визначає, який синтаксис нижче потрібно використовувати.

Найнаочніше це видно на прикладі Docker, який публікує окрему команду для налаштування репозиторію кожної версії. У RHEL і його rebuild-дистрибутивах з 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 і проміжними релізами на сервері — це те саме рішення у світі 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?

Ні. Personal package archives — це сервіс 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 — це symbolic link на 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 позначив його як потрібний самостійно.