AlmaLinux и Rocky Linux: DNF, EPEL, CRB и конфликты зависимостей

AlmaLinux и Rocky Linux часто выбирают для серверов, где важны предсказуемые обновления, долгий жизненный цикл и совместимость с экосистемой Enterprise Linux. Но у этой стабильности есть обратная сторона: пакеты распределены по нескольким репозиториям, часть зависимостей вынесена в CRB, а популярные утилиты и библиотеки приходят из EPEL. Если включить всё в неправильном порядке или смешать пакеты разных веток, DNF быстро покажет знакомое: nothing provides, conflicting requests, package does not belong to a distupgrade repository или предложит удалить полсистемы.

В этой инструкции разберём, как устроены базовые репозитории AlmaLinux и Rocky Linux, чем CRB repository отличается от BaseOS и AppStream, зачем нужен EPEL и почему dependency conflicts почти всегда можно диагностировать без паники. Материал рассчитан на администраторов, которые обслуживают VDS, веб-серверы, CI-раннеры, почтовые узлы, панели управления и обычные production-сервисы на EL-подобных дистрибутивах.

Главное правило: перед исправлением конфликта не надо сразу добавлять сторонние репозитории и запускать установку с --allowerasing. Сначала определяем версию ОС, включённые репозитории, происхождение конфликтного пакета и только потом меняем состояние системы.

Почему на AlmaLinux и Rocky Linux появляются dependency conflicts

DNF работает поверх RPM-базы и решает задачу зависимостей: какой пакет, какой версии и из какого репозитория можно установить так, чтобы не сломать уже установленное. В идеальном мире все пакеты доступны в одном репозитории и собраны в один день. В реальности на сервере могут быть BaseOS, AppStream, Extras, CRB, EPEL, EPEL Next, репозитории панелей управления, PHP-стеков, баз данных, мониторинга и вручную скачанные rpm-пакеты. У каждого источника свои версии библиотек, свои зависимости и свои правила обновления.

Типовая проблема выглядит так: администратор ставит пакет из EPEL, например утилиту для бэкапов, мониторинга или обработки изображений. DNF отвечает, что не хватает библиотеки -devel, Perl-модуля, Python-модуля или пакета libsomething. Сам пакет есть в EPEL, а зависимость лежит в CRB. Если CRB выключен, решатель DNF просто не видит нужный пакет и сообщает, что зависимость не удовлетворена.

Вторая частая причина — смешение веток. Например, на AlmaLinux 9 случайно подключили rpm от EL8, оставили старый репозиторий после миграции, поставили пакет с суффиксом el8 на систему el9 или наоборот. Иногда сервер пережил inplace-апгрейд, но в /etc/yum.repos.d/ остались старые файлы. DNF видит пакеты, но их зависимости построены для другой ABI-версии, поэтому конфликт становится неразрешимым без удаления или замены пакетов.

Третья причина — сторонние репозитории, которые перекрывают системные пакеты. Это может быть удобно для новых версий PHP, MariaDB, PostgreSQL, Nginx или Node.js, но опасно без приоритетов и контроля. Если сторонний репозиторий предоставляет библиотеку с тем же именем, что и AppStream, DNF может выбрать более новую или более старую сборку, а затем получить конфликт при следующем обновлении.

Четвёртая причина — ручная установка rpm. Команда rpm полезна для диагностики, но при установке пакетов напрямую она не решает зависимости так же удобно, как DNF. Если пакет поставлен вручную, без репозитория, обновлять его сложнее: DNF не знает, откуда брать совместимую версию, и может считать пакет инородным.

BaseOS, AppStream, Extras, CRB и EPEL: что за что отвечает

В Enterprise Linux-подобных системах базовая раскладка примерно такая. BaseOS содержит фундамент системы: ядро, systemd, glibc, базовые утилиты, сеть, storage-компоненты. AppStream хранит прикладные стеки и модули: языки, базы данных, веб-компоненты, часть серверного софта. Extras обычно содержит дополнительные пакеты, которые помогают подключать внешние репозитории или расширяют систему без вмешательства в базовую платформу.

CRB repository, или CodeReady Builder, — важная часть картины. В AlmaLinux 9 и Rocky Linux 9 он обычно называется crb. В EL8-подобных системах аналогичный репозиторий часто назывался powertools. Там лежит много пакетов, которые нужны для сборки, разработки и зависимостей: -devel, дополнительные библиотеки, заголовочные файлы, модули для языков, инструменты, без которых EPEL-пакеты не всегда устанавливаются.

EPEL — Extra Packages for Enterprise Linux. Это популярный внешний репозиторий с большим количеством пакетов, которых нет в базовой поставке. Для админов это источник множества удобных инструментов: от мониторинга и CLI-утилит до библиотек, демонов и вспомогательного ПО. Но EPEL не заменяет BaseOS, AppStream и CRB: он дополняет их. Поэтому включать EPEL без CRB на AlmaLinux и Rocky Linux — частый путь к конфликтам.

Важно понимать: EPEL-пакеты собираются с расчётом на включённые системные репозитории соответствующей версии EL. Если на Rocky Linux EPEL подключён для неправильной major-версии или если CRB выключен, проблема не в качестве EPEL, а в несогласованном наборе источников.

Быстрая диагностика: сначала узнаём версию системы и репозитории

Перед любыми действиями проверьте, что сервер действительно работает на той версии AlmaLinux или Rocky Linux, под которую подключены репозитории. Особенно это важно на VDS после миграций, восстановления из старого образа или ручного переноса /etc/yum.repos.d/.

cat /etc/os-release
rpm -E %rhel
uname -r
dnf --version

Команда rpm -E %rhel покажет major-версию платформы: например, 8, 9 или 10. Это удобно, когда в имени пакета или репозитория есть суффикс el9, а вы хотите быстро убедиться, что он соответствует системе.

Затем смотрим включённые и выключенные репозитории:

dnf repolist
dnf repolist --all
ls -1 /etc/yum.repos.d/

Если в списке нет crb на EL9 или powertools на EL8, а вы устанавливаете пакет из EPEL, это первый кандидат на причину ошибки. Также обратите внимание на старые файлы репозиториев: названия с CentOS-8, el8 на EL9, архивные зеркала, временные testing-репозитории, файлы от удалённых панелей управления.

Полезно проверить, какие пакеты установлены не из текущих репозиториев. На разных версиях DNF набор плагинов и вывод отличаются, но базовая идея одна: найти инородные пакеты, которые не имеют источника в активной конфигурации.

dnf list extras
dnf repoquery --unsatisfied
dnf check

dnf check покажет проблемы RPM-базы: недостающие зависимости, дубликаты, конфликтующие пакеты. dnf repoquery --unsatisfied помогает увидеть уже установленные пакеты, у которых зависимости не удовлетворены. Если команда недоступна, установите плагины DNF.

dnf install dnf-plugins-core

Как правильно включить CRB на AlmaLinux и Rocky Linux

На EL9-подобных системах включение CRB обычно выполняется через dnf config-manager. Этот инструмент входит в пакет dnf-plugins-core. Если команды нет, сначала установите плагин.

dnf install dnf-plugins-core
dnf config-manager --set-enabled crb
dnf repolist

На EL8-подобных системах вместо crb часто используется powertools:

dnf install dnf-plugins-core
dnf config-manager --set-enabled powertools
dnf repolist

После включения репозитория обновите метаданные. Это особенно важно, если до этого DNF уже кэшировал состояние без CRB.

dnf clean all
dnf makecache

Не стоит редактировать файлы репозиториев вручную без необходимости. Да, можно открыть /etc/yum.repos.d/almalinux-crb.repo или аналогичный файл Rocky Linux и поменять enabled=0 на enabled=1, но dnf config-manager безопаснее и лучше подходит для повторяемых инструкций. Кроме того, ручное редактирование легко забыть при автоматизации Ansible, cloud-init или bootstrap-скриптов.

Как подключить EPEL без лишнего риска

На AlmaLinux и Rocky Linux EPEL обычно подключают через пакет epel-release. Перед этим убедитесь, что включены базовые репозитории и CRB. Порядок важен: сначала системные источники, потом EPEL, затем установка прикладных пакетов.

dnf install epel-release
dnf repolist
dnf makecache

После подключения посмотрите, как называются активные репозитории. Обычно вы увидите epel, иногда дополнительно epel-cisco-openh264 или другие сопутствующие источники в зависимости от версии. Не включайте testing-репозитории на production-сервере без явной причины. Они полезны для проверки будущих сборок, но могут привести к dependency conflicts при обычном обновлении.

Если пакет нужен только один раз, можно временно включить или выключить репозиторий на уровне конкретной команды. Это удобно, когда вы не хотите, чтобы EPEL участвовал во всех обновлениях, но хотите поставить конкретную утилиту.

dnf install htop --enablerepo=epel
dnf update --disablerepo=epel

Для production-серверов я предпочитаю явную политику: либо EPEL считается постоянным источником и участвует в обновлениях, либо используется точечно и документируется. Промежуточное состояние, когда на сервере часть пакетов из EPEL, но сам репозиторий отключён, часто приводит к неожиданным конфликтам через несколько месяцев.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Как читать типичные ошибки DNF

Ошибки DNF кажутся шумными, но в них обычно есть все подсказки. Главное — не смотреть только на последнюю строку. Важны имена пакетов, версии, суффиксы el8/el9, репозитории и фразы о том, что именно не найдено.

nothing provides

Это означает, что DNF не видит пакет или виртуальную зависимость, которую требует устанавливаемый пакет. Частый сценарий: зависимость есть в CRB, но CRB выключен.

Error:
 Problem: conflicting requests
  nothing provides libexample-devel needed by example-tool-1.2.3-1.el9.x86_64

Проверяем наличие пакета в доступных репозиториях:

dnf provides libexample-devel
dnf repoquery --whatprovides libexample-devel
dnf repolist --all

Если после включения CRB пакет находится, проблема решена. Если не находится, проверьте major-версию ОС и происхождение пакета, который требует эту зависимость.

conflicting requests

Эта фраза сама по себе не говорит о причине. Она означает, что набор требований нельзя удовлетворить одновременно. Причиной может быть выключенный репозиторий, конфликт версий, дублирующий пакет или неверная ветка EPEL.

dnf install package-name --best

Параметр --best просит DNF не подбирать молча более старую доступную версию, а показать, почему лучшая версия не устанавливается. Это хороший диагностический режим перед тем, как принимать решение.

package is filtered out by modular filtering

Модульность AppStream может скрывать часть пакетов, если активирован другой stream. На EL8 это встречается чаще, на EL9 — реже, но всё ещё возможно для некоторых стеков.

dnf module list
dnf module list php
dnf module list postgresql

Не сбрасывайте модули вслепую. Сначала проверьте, какие пакеты зависят от текущего stream, и подготовьте откат. На веб-сервере смена stream PHP или PostgreSQL может затронуть приложение сильнее, чем кажется; если отдельно обслуживаете PostgreSQL, пригодится материал про настройку PostgreSQL, autovacuum и индексы.

Безопасный план исправления конфликтов

Когда DNF ругается на зависимости, действуйте по шагам. Такой порядок экономит время и снижает риск случайно удалить важный пакет на рабочем сервере.

1. Зафиксируйте текущее состояние: версия ОС, список репозиториев, полный текст ошибки DNF.
2. Проверьте, включён ли CRB или PowerTools для вашей major-версии.
3. Обновите кэш DNF и повторите установку с --best.
4. Найдите, из какого репозитория пришёл конфликтный пакет.
5. Проверьте инородные и дублирующиеся rpm-пакеты.
6. Только после диагностики используйте --allowerasing или distro-sync.

Сначала соберите информацию:

cat /etc/os-release
rpm -E %rhel
dnf repolist --all
dnf check
dnf list extras

Потом проверьте конкретный пакет:

dnf info package-name
dnf repoquery --requires package-name
dnf repoquery --deplist package-name
dnf repoquery --whatrequires package-name

Если пакет уже установлен, полезно узнать его происхождение:

dnf repoquery --installed package-name
rpm -qi package-name
rpm -q --whatrequires package-name

rpm -qi покажет сведения из RPM-заголовка: версию, релиз, сборщика, дату установки. Если пакет был установлен вручную или пришёл из неактивного репозитория, это часто видно по имени релиза и vendor-полю.

Когда использовать --allowerasing, а когда нельзя

Параметр --allowerasing разрешает DNF удалять установленные пакеты, если это помогает решить зависимости. Это не зло, но это инструмент для осознанного применения. На сервере с панелью управления, почтой, несколькими версиями PHP или нестандартной базой данных он может предложить удалить важные компоненты.

dnf install package-name --best --allowerasing

Перед подтверждением внимательно читайте блок Removing. Если DNF предлагает удалить библиотеку, которая тянет за собой десятки пакетов, остановитесь. Часто правильнее включить CRB, отключить конфликтующий сторонний репозиторий или заменить один пакет на сборку из правильной ветки.

Хорошая практика — сначала выполнить команду без подтверждения и сохранить вывод. Если сервер критичный, проверьте то же действие на staging-копии или свежей тестовой VDS с той же версией ОС и тем же набором репозиториев. Конфликты зависимостей намного спокойнее разбирать там, где перезапуск сервиса не влияет на пользователей.

distro-sync: мощно, но осторожно

dnf distro-sync синхронизирует установленные пакеты с версиями из включённых репозиториев. В отличие от обычного обновления, он может не только повышать, но и понижать версии пакетов. Это полезно после отключения неправильного репозитория или исправления ветки, но опасно при неясной конфигурации.

dnf distro-sync --assumeno

Параметр --assumeno позволяет посмотреть план без изменений. Если план выглядит разумно, можно запускать уже без него. Но если DNF предлагает массовые downgrade или удаление системных компонентов, сначала разберитесь с репозиториями.

dnf distro-sync

Типичный сценарий применения: на Rocky Linux 9 случайно был подключён репозиторий для другой ветки, несколько пакетов обновились до неподходящих релизов, после чего обычный dnf update стал падать. Вы отключаете неверный репозиторий, включаете штатные BaseOS, AppStream, CRB, EPEL для EL9, обновляете метаданные и проверяете distro-sync --assumeno. Если DNF предлагает вернуть несколько пакетов к корректным версиям, это может быть правильным лечением.

Версионные блокировки, exclude и старые rpm: скрытые источники проблем

Иногда CRB включён, EPEL правильный, репозитории выглядят чисто, но dependency conflicts остаются. Тогда проверьте блокировки версий и исключения. На сервере могли когда-то зафиксировать версию ядра, PHP, MariaDB, OpenSSL-совместимой библиотеки или пакета панели управления.

dnf versionlock list
grep -R exclude /etc/dnf /etc/yum.repos.d
grep -R includepkgs /etc/dnf /etc/yum.repos.d

Если dnf versionlock недоступен, может потребоваться соответствующий плагин. Сама идея проста: заблокированная старая версия не даёт DNF поставить новую зависимость, а новая зависимость требует обновления старого пакета. В результате решатель видит тупик.

Отдельно проверьте дубликаты:

dnf repoquery --duplicates
dnf remove --duplicates

Команда удаления дубликатов может быть полезной после прерванного обновления, но перед применением изучите план. На системах с нестандартными репозиториями она иногда предлагает больше, чем вы ожидали.

Практический пример: EPEL-пакет не ставится без CRB

Представим типовую ситуацию. Есть свежая AlmaLinux 9 или Rocky Linux 9. Администратор подключил EPEL и пытается поставить пакет example-tool. DNF сообщает, что не найден libexample-devel. Сначала проверяем систему:

rpm -E %rhel
dnf repolist

Видим, что epel включён, а crb отсутствует. Включаем CRB:

dnf install dnf-plugins-core
dnf config-manager --set-enabled crb
dnf clean all
dnf makecache

Проверяем зависимость:

dnf provides libexample-devel
dnf install example-tool --best

Если установка проходит, конфликт был не конфликтом версий, а неполным набором репозиториев. Это самый частый и самый приятный вариант: ничего удалять, понижать или чинить в RPM-базе не нужно.

Практический пример: пакет из неправильной ветки EL

Теперь другая ситуация. На сервере Rocky Linux 9 установлен пакет с релизом el8. Он требует старую версию библиотеки, а обновление тянет новую. DNF не может совместить обе зависимости. Проверяем пакет:

rpm -qi package-name
dnf repoquery --installed package-name
dnf list extras

Если пакет не принадлежит активным репозиториям, нужно решить, чем его заменить. Варианты: найти корректный пакет для EL9, подключить правильный репозиторий поставщика, удалить пакет, если он больше не нужен, или перенести сервис на поддерживаемый стек. Худший вариант — продолжать добавлять репозитории наугад, пока зависимость не найдётся. Так можно получить систему, которая обновляется только вручную и ломается при каждом security update.

Рекомендации для серверов с панелями, PHP-стеками и базами данных

На VDS с веб-панелью или несколькими сайтами зависимости сложнее, чем на минимальном сервере. Панели часто подключают собственные репозитории, управляют версиями PHP, Nginx, Apache, почтовых компонентов и баз данных. Если поверх этого добавить EPEL, CRB, сторонний репозиторий PHP и репозиторий базы данных без политики приоритетов, DNF будет решать очень сложную задачу.

Практичный подход такой: документируйте каждый внешний репозиторий и причину его появления. Не оставляйте testing-источники включёнными после разовой установки. Не ставьте rpm вручную, если поставщик поддерживает нормальный репозиторий. Перед крупным обновлением снимайте резервную копию и сохраняйте вывод dnf repolist --all, dnf list installed, rpm -qa. Это помогает быстро понять, что изменилось.

Для PHP и баз данных особенно важно не смешивать системные модули AppStream и сторонние сборки без необходимости. Если вы выбрали внешний репозиторий для PHP, лучше управлять всем PHP-стеком из одного источника. Если PostgreSQL или MariaDB установлены из репозитория поставщика, не позволяйте случайным пакетам из другого источника перекрывать клиентские библиотеки.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Мини-чек-лист перед установкой пакета из EPEL

• Проверьте major-версию ОС через rpm -E %rhel.
• Убедитесь, что включены BaseOS, AppStream и Extras.
• Для EL9 включите crb, для EL8 — powertools.
• Подключайте epel-release из штатного для вашей системы источника.
• Не используйте EPEL для другой major-версии.
• Проверяйте план DNF перед подтверждением установки.
• Не применяйте --allowerasing, пока не поняли, что будет удалено.

Что делать, если DNF уже сломан после неудачных действий

Если обновление прервалось, репозитории смешались или часть пакетов установлена вручную, начните с инвентаризации. Не пытайтесь сразу чинить всё одной командой. Сохраните вывод диагностики в файл, чтобы можно было сравнить состояние до и после.

dnf check
dnf repolist --all
dnf list extras
dnf repoquery --unsatisfied
dnf repoquery --duplicates

Затем временно отключите явно неправильные репозитории. Не удаляйте файлы сразу: лучше поменять состояние через dnf config-manager или перенести файл в отдельный каталог, чтобы понимать, что именно изменили. После этого очистите кэш и проверьте план синхронизации.

dnf clean all
dnf makecache
dnf distro-sync --assumeno

Если конфликт связан с одним пакетом, иногда проще удалить его и установить заново из правильного источника. Но для системных библиотек, web stack, почтовых компонентов и баз данных такой подход требует осторожности: удаление может остановить сервис или снести зависимые пакеты. Перед изменениями проверьте, что у вас есть актуальный бэкап конфигураций и данных.

Профилактика: как не возвращаться к тем же конфликтам

Самая надёжная профилактика — минимальный и понятный набор репозиториев. Для большинства серверов достаточно штатных репозиториев AlmaLinux или Rocky Linux, CRB и EPEL. Всё остальное добавляйте только под конкретную задачу: свежий PostgreSQL, альтернативный PHP, observability-агент, панель управления. Чем меньше источников перекрывают одни и те же библиотеки, тем стабильнее обновления.

Второй принцип — повторяемость. Если вы разворачиваете несколько VDS, не настраивайте репозитории вручную в SSH-сессии без записи. Оформите команды в Ansible, cloud-init, shell-скрипт bootstrap или хотя бы в runbook. Тогда через полгода будет понятно, почему включён CRB, откуда взялся EPEL и какие репозитории должны быть выключены.

Третий принцип — проверка перед обновлением. На production-сервере полезно сначала запускать:

dnf check-update
dnf update --assumeno

Так вы заранее увидите, какие пакеты будут обновлены, удалены или заменены. Если в плане внезапно появляются downgrade, массовое удаление или переход пакетов между репозиториями, это сигнал остановиться и разобраться.

Четвёртый принцип — не игнорировать мелкие предупреждения. Один инородный rpm сегодня может не мешать, но через несколько месяцев он станет причиной конфликта при обновлении OpenSSL-совместимой библиотеки, Python-модуля или системного клиента базы данных. Регулярно просматривайте dnf list extras и держите список исключений осознанным.

Короткий итог

В AlmaLinux DNF и Rocky Linux dependency conflicts чаще всего появляются из-за неполного набора репозиториев, особенно когда EPEL включён, а CRB repository выключен. На EL9 включайте crb, на EL8 проверяйте powertools, не смешивайте rpm-пакеты разных major-версий и не используйте --allowerasing как первую реакцию на ошибку.

Если действовать спокойно, DNF обычно даёт достаточно информации для диагностики: версия ОС, список репозиториев, источник пакета, недостающая зависимость и план изменений. Сначала собираем факты, затем включаем нужные системные репозитории, проверяем EPEL, чистим метаданные и только потом применяем более сильные инструменты вроде distro-sync. Такой подход сохраняет сервер обновляемым, предсказуемым и удобным в сопровождении.