ALT Linux и apt-rpm: почему привычные команды ведут себя иначе

MAATRIX

Если вам выдали сервер на ALT Linux — по требованию заказчика, из-за реестра отечественного ПО или просто потому, что так исторически сложилось в компании, — первая же команда apt-get install может повести себя не так, как вы привыкли. Пакет не находится под именем, к которому вы привыкли, автоочистка оставляет не то, что должна, а гайд из интернета для «apt» почему-то не работает один в один. Дело не в баге и не в кривых руках — дело в том, что apt в ALT Linux работает поверх RPM, а не поверх DEB, и это меняет поведение на уровне, который редко объясняют в общих статьях про Linux.

Что такое apt-rpm и зачем он в ALT Linux

apt — это менеджер пакетов высокого уровня, который решает зависимости, скачивает пакеты из репозиториев и передаёт их низкоуровневому инструменту для установки. В Debian и Ubuntu под капотом у apt лежит dpkg и пакеты формата .deb. В ALT Linux под тем же самым фронтендом apt лежит RPM — пакеты формата .rpm, тот же формат, что используют RHEL, CentOS/AlmaLinux, Fedora и openSUSE.

Это не случайное совпадение и не костыль конкретно ALT. Связка apt-фронтенда с rpm-бэкендом существует в Linux-экосистеме давно как отдельное направление разработки, отдельное от классического dpkg-apt и отдельное от yum/dnf. ALT Linux выбрал именно этот путь: сохранить привычный синтаксис команд apt (apt-get update, apt-get install, apt-cache search и так далее), но работать с пакетами и зависимостями в формате RPM.

Практический смысл в том, что вы получаете знакомый интерфейс командной строки — но семантика операций местами наследуется не от dpkg, а от мира RPM. И там, где dpkg и rpm устроены по-разному, поведение apt в ALT Linux будет ближе к RPM, а не к тому, что вы видели в Debian.

Три лагеря администраторов — и у каждого свои ожидания

Путаница вокруг apt-rpm обычно возникает у трёх разных категорий администраторов, и у каждой свой набор ложных ожиданий.

• Админы с опытом Debian/Ubuntu видят знакомые команды apt-get и подсознательно ждут полного соответствия поведению dpkg-мира: те же правила именования пакетов, ту же логику конфликтов конфигов, тот же смысл у purge и autoremove. Синтаксис совпадает, семантика — местами нет.
• Админы с опытом RHEL/CentOS/Fedora знают, что перед ними RPM-пакеты, и по привычке лезут за yum или dnf — которых в базовой поставке ALT просто нет. Приходится переучиваться на apt-синтаксис при том, что низкоуровневая логика пакетов им уже знакома.
• Те, кто в целом не Linux-администратор, а просто выполняет установку по гайду из интернета, страдают больше всех: любой сгенерированный ИИ или найденный по первой ссылке туториал «как поставить nginx на Linux» почти всегда написан под Debian/Ubuntu или под RHEL-семейство — и в лучшем случае половина команд не сработает.

Если вы администрируете сервер на ALT Linux впервые после Ubuntu, стоит заранее принять: синтаксис у вас общий, а вот интуиция про то, «что должно произойти», — нет. Похожая история случается и при переезде между другими российскими и «привычными» дистрибутивами: мы разбирали это на примере перехода с Ubuntu на Astra Linux — там ломается другой набор вещей, но сам принцип «синтаксис знакомый, поведение — нет» тот же самый.

Что конкретно ведёт себя иначе

Вот основные точки расхождения, из-за которых привычные рефлексы дают сбой.

Имена пакетов. В экосистеме Debian/Ubuntu пакеты с заголовочными файлами и библиотеками для разработки называются с суффиксом -dev (libssl-dev, libpq-dev). В RPM-мире, к которому принадлежит ALT, исторически принят суффикс -devel (libssl-devel, libpq-devel). Если вы на автопилоте набираете apt-get install libssl-dev на ALT, скорее всего получите «пакет не найден» — не потому что его нет, а потому что называется он иначе. Первое, что стоит сделать при «пакет не найден» на ALT — не спорить с системой, а поискать точное имя через apt-cache search по ключевому слову.

Работа с конфигурационными файлами при обновлении и удалении. В dpkg есть явное разделение: remove удаляет сам пакет, но оставляет изменённые конфиги, а purge удаляет и их. У RPM своя механика — при конфликте изменённого конфига с новой версией из пакета система обычно сохраняет пользовательский вариант рядом с суффиксом (условно — что-то вроде .rpmsave/.rpmnew, точное поведение зависит от того, как конкретный пакет описывает свои конфиги), а не ведёт отдельный список «conffiles», как dpkg. Ожидать от apt-get remove и apt-get purge на ALT ровно того же контракта, что в Debian, не стоит — логика сохранения и подмены конфигов там устроена на уровне RPM-спеки конкретного пакета, а не универсального правила apt.

Автоочистка неиспользуемых зависимостей. apt-get autoremove в Debian опирается на граф зависимостей dpkg и на пометку «пакет был установлен как зависимость». RPM хранит зависимости иначе, и то, что apt-rpm посчитает «осиротевшим» пакетом, не обязательно совпадёт один в один со списком, который вы бы увидели в Debian на аналогичном наборе софта. Перед автоочисткой на проде разумно сначала посмотреть список кандидатов, а не запускать команду вслепую по привычке.

Инспекция установленных пакетов. Рефлекс dpkg -l или dpkg -L имя-пакета (список файлов пакета) на ALT не сработает — dpkg там просто не установлен как основной инструмент управления пакетами. Вместо этого работают прямые RPM-запросы:

rpm -qa                  # список всех установленных пакетов
rpm -qi имя-пакета       # подробная информация о пакете
rpm -ql имя-пакета       # список файлов, которые пакет установил

Это не «замена одной команды другой» механически — это другой инструмент с другой моделью данных под капотом, apt в ALT с ним сосуществует, а не подменяет собой.

Исходные пакеты. В Debian у многих привычна связка «взять исходники пакета через apt, чуть поправить, пересобрать». В RPM-мире аналогичная роль у src.rpm и своей инфраструктуры сборки — механика получения исходников и правила именования отличаются от Debian-варианта, и полагаться на дословное повторение debian-команд для сборки из исходников не стоит: там своя цепочка инструментов.

Репозитории и ветки: не релизы Debian, а Sisyphus и пронумерованные ветки

Ещё один источник путаницы — модель релизов. У Debian три ветки в привычном понимании (stable/testing/unstable) и чёткий цикл LTS. У ALT Linux своя модель:

• Sisyphus — постоянно обновляемая (rolling) ветка разработки, аналог unstable, но не «привязанная» к будущему релизу так же жёстко, как Debian sid;
• пронумерованные стабильные ветки (в духе p10, p11 и так далее) — снапшоты Sisyphus, которые дальше сопровождаются отдельно, ближе по духу к Debian stable, но со своим циклом обновлений и поддержки.

Список репозиториев в ALT задаётся строками, начинающимися с rpm, а не с deb — потому что источник, как ни крути, RPM-репозиторий:

# иллюстративный пример — точный набор зеркал и веток
# смотрите в актуальной документации ALT для вашей версии
rpm [alt] p10/branch/x86_64 classic
rpm [alt] p10/branch/noarch classic

Добавлять и переключать репозитории на ALT принято через отдельную утилиту apt-repo, а не редактированием sources.list руками и не через add-apt-repository — этой команды в базовой поставке ALT нет, в отличие от Ubuntu, где PPA давно стали привычным способом подключить сторонний софт. Если вы по инерции ищете «PPA для ALT» — такого понятия в этой экосистеме нет, обновление стороннего ПО решается через собственные репозитории и ветки apt-rpm.

Смена ветки (условно — переход на новую стабильную версию системы) концептуально ближе к обновлению между релизами Debian, чем к rolling-обновлению Sisyphus: меняете источники на новую ветку, затем выполняете полное обновление пакетов — но перед этим стоит свериться с официальным разделом обновления версий именно для ALT, а не действовать по памяти с Ubuntu-гайда о do-release-upgrade.

Практические грабли: как это выглядит на живом сервере

Несколько ситуаций, которые чаще всего ловят администраторов, впервые администрирующих ALT после Debian-подобных систем.

• «Unable to locate package» на пакете, который точно есть в системе. Причина почти всегда одна — вы ищете его под Debian-именем (-dev, другое написание). Решение: apt-cache search по части названия, а не по точному имени из старого гайда.
• Автоочистка убирает не то, что вы ожидали (или не убирает то, что явно не нужно). Причина — другая логика графа зависимостей RPM. Решение: смотреть список кандидатов на удаление перед подтверждением, не полагаться на память о поведении Debian.
• GPG-ключи репозиториев подключаются не так, как в Debian-гайдах. В мире dpkg-apt давно ушли от apt-key в пользу файлов в trusted.gpg.d; в RPM-мире исторически принят прямой импорт ключа через rpm --import. Механика похожая по смыслу («система должна доверять подписи репозитория»), но команды и файлы другие — копировать инструкцию «добавь ключ apt-key adv --recv-keys» с Debian-форума бессмысленно.
• Ожидание пакетов из общего PPA или стороннего deb-репозитория. Если сторонний вендор публикует только .deb, для ALT это не сработает без пересборки в RPM — это разные бинарные форматы, а не разная упаковка одного и того же содержимого.
• Скрипты автоматизации (Ansible/Salt/самописные), написанные под apt Debian-модуль. Модули для управления пакетами через apt в системах автоматизации иногда жёстко подразумевают dpkg-семантику (статусы установки, формат вывода). На ALT их стоит проверять отдельно, а не доверять слепо, даже если синтаксис вызова совпадает.

Отдельно стоит сказать про безопасность: раз статья в категории security, важно понимать, что путаница в поведении команд — это не только неудобство, но и риск. Администратор, уверенный, что apt-get purge гарантированно вычистил конфиги с секретами, или что autoremove убрал именно то, что убрал бы в Debian, может ошибочно считать систему в известном состоянии, когда это не так. Проверяйте результат команды (rpm -qa, rpm -ql, явный просмотр файловой системы), а не только код возврата и привычную по Debian интуицию.

Где искать документацию именно под ALT Linux

Главная практическая рекомендация: не гуглить общий Debian- или Ubuntu-гайд и не пытаться транслировать RHEL/dnf-инструкцию буквально. Синтаксис похож на оба лагеря, а поведение — нет, поэтому берите источники, написанные конкретно про ALT:

• Официальная вики ALT Linux (wiki.altlinux.org) — основной справочник по системным утилитам, включая специфичные для ALT инструменты вроде apt-repo, модель веток и репозиториев.
• Поиск пакетов ALT (packages.altlinux.org) — там видно точное имя пакета в нужной ветке, что снимает большинство проблем с «пакет не найден» из-за разницы в именовании.
• Документация Basealt — компании-разработчика ALT Linux, которая ведёт материалы под сертифицированные и защищённые конфигурации (актуально, если сервер разворачивается под требования регулятора, а не просто «потому что отечественный дистрибутив»).
• Форум и списки рассылки ALT — там же обсуждаются реальные грабли конкретных версий и веток, а не общие принципы.
• man-страницы, установленные вместе с системой — они описывают именно ту реализацию apt-rpm, которая стоит у вас, а не общий Debian-апт из статьи десятилетней давности.

Если сомневаетесь, применима ли конкретная команда или флаг из общего Linux-гайда к ALT — не проверяйте это на проде. Прогоните на тестовом окружении или хотя бы прочитайте man перед тем, как выполнять операцию с пакетами на боевом сервере. Разница между apt-фронтендом Debian и apt-фронтендом ALT достаточно тонкая, чтобы ошибиться было легко, и достаточно значимая, чтобы ошибка стоила дорого — от неудалённого конфига с паролем до сломанной сборки после смены ветки. Если тема выбора дистрибутива для сервера в целом ещё открыта, полезно заодно свериться со сравнением Ubuntu и Debian — оно объясняет происхождение той самой dpkg-логики, от которой отталкивается большинство ожиданий, ломающихся на ALT.

Частые вопросы