Библиотека — Linux — пакетные менеджеры: deb, rpm, pacman, универсальные форматы [X]
Шифр
linux-package-managers
Разделы
linux tooling
Сверено
2 сентября — в этот день утверждения статьи сверялись с первоисточниками, а не правился текст
Объём
19 189 знаков · 20 разделов · чтения около 20 минут

Linux — пакетные менеджеры: deb, rpm, pacman, универсальные форматы

Обзор

Управление пакетами — одна из областей, где Linux радикально отличается от FreeBSD и где фрагментация дистрибутивов ощущается сильнее всего. В FreeBSD есть pkg (единый пакетный менеджер для портов и бинарных пакетов) и ports tree (единый source tree). В Linux исторически сложились два доминирующих формата — deb (Debian/Ubuntu) и rpm (Red Hat/Fedora/SUSE) — плюс несколько альтернативных (pacman в Arch, portage в Gentoo), а в последние годы добавились «универсальные» форматы (Flatpak, Snap, AppImage), решающие проблему кросс-дистрибутивной совместимости.

Архитектура всех систем двухуровневая: низкоуровневый инструмент (dpkg, rpm, pacman) работает с отдельными пакетами, а высокоуровневый фронтенд (apt, dnf, pacman сам является обоими) управляет репозиториями, зависимостями и транзакциями.

deb: dpkg + APT

Формат пакета

.deb — ar-архив, содержащий три компонента: debian-binary (версия формата, обычно «2.0»), control.tar.xz (метаданные: control file с описанием, зависимостями, maintainer scripts), data.tar.xz (собственно файлы, устанавливаемые в систему). Алгоритм сжатия форматом не зафиксирован: Debian собирает пакеты с xz, а Ubuntu переключила умолчание dpkg-deb на zstd, так что там внутри лежит data.tar.zst.

control file описывает зависимости в нескольких уровнях: Depends (обязательные — пакет не функционирует без них), Pre-Depends (должны быть установлены до распаковки — используется редко, для критических upgrade-сценариев), Recommends (установленные по умолчанию через apt, но не обязательные), Suggests (опциональные), Conflicts/Breaks (несовместимость). Виртуальные пакеты позволяют нескольким реализациям удовлетворять одну зависимость: Depends: default-mta | mail-transport-agent — подойдёт любой MTA.

Maintainer scripts (preinst, postinst, prerm, postrm) выполняются в определённые моменты жизненного цикла: до/после распаковки, до/после удаления. Это произвольный shell-код — мощный механизм, но и источник проблем: сломанный postinst может оставить пакет в состоянии half-configured.

Двухуровневая архитектура: dpkg и APT

dpkg — низкоуровневый инструмент. Устанавливает/удаляет один .deb файл, не знает о репозиториях и не умеет разрешать зависимости. Ведёт базу данных установленных пакетов в /var/lib/dpkg/. Ключевые состояния пакета: installed, half-installed, half-configured, unpacked, config-files (удалён, но конфиги остались).

APT (Advanced Package Tool) — высокоуровневый фронтенд: скачивает пакеты из репозиториев, разрешает зависимости, вызывает dpkg для фактической установки. apt — современный CLI (apt install, apt search, apt upgrade). apt-get/apt-cache — старый, более скриптопригодный CLI (стабильный вывод, не меняющийся между версиями). aptitude — альтернативный фронтенд с более агрессивным dependency solver (умеет предлагать удаление пакетов для разрешения конфликтов). APT 3.0 (апрель 2025) сменил внешний вид apt: цвета, колоночный вывод списков пакетов, удаления показываются последними. В apt 3.1 (октябрь 2025) умолчанием стал solver3 — полноценный backtracking-решатель вместо прежней эвристики.

Репозитории описываются в /etc/apt/sources.list и /etc/apt/sources.list.d/. Формат deb822 (файлы *.sources) вытесняет однострочный: apt считает старый формат устаревшим и планирует убрать его не раньше 2029 года, сам apt поставляет теперь debian.sources/ubuntu.sources вместо sources.list, а команда apt modernize-sources (появилась в apt 2.9.26, январь 2025) конвертирует старые .list автоматически — Debian 13 прямо рекомендует ей воспользоваться после обновления:

# Новый формат (deb822)
Types: deb
URIs: http://deb.debian.org/debian
Suites: trixie
Components: main contrib non-free non-free-firmware

Multi-arch

Debian поддерживает установку пакетов для нескольких архитектур одновременно (например, i386-библиотеки на amd64-системе). Пакеты с Multi-Arch: same устанавливают файлы в архитектурно-специфичные пути (/usr/lib/x86_64-linux-gnu/ vs /usr/lib/i386-linux-gnu/). dpkg --add-architecture i386 && apt update && apt install libc6:i386 — типичный сценарий для запуска 32-битного софта.

rpm: rpm + DNF

Формат пакета

.rpm — cpio-архив с заголовком, содержащим метаданные. Структура зависимостей аналогична deb: Requires, Provides, Conflicts, Obsoletes. Отличие: rpm нативно поддерживает file-level dependencies (зависимость может быть на конкретный файл: Requires: /usr/bin/python3) и capabilities (абстрактные «возможности»).

В сентябре 2025 года rpm 6.0 ввёл новую версию формата — v6: все размеры 64-битные, строки всегда в UTF-8, устаревшая криптография выброшена в пользу SHA-256/SHA-3, payload проверяется независимо от остальных секций, а типы файлов хранятся как MIME вместо строк libmagic. v4-пакеты rpm 6 по-прежнему читает, а собираемый формат выбирается макросом %_rpmformat (upstream-умолчание — уже 6).

Spec-файл описывает и сборку, и метаданные пакета — единый файл вместо разделённого debian/ директория. Это проще для понимания, но менее гибко при сложных сборках.

DNF (Dandified YUM)

DNF — высокоуровневый менеджер для rpm. Пришёл на смену YUM (который был переписан из-за проблем с производительностью и dependency resolution). DNF использует libsolv (SAT-solver) для разрешения зависимостей — тот же solver, что в SUSE zypper.

DNF 5 (C++ rewrite, с Fedora 41 — default) значительно быстрее DNF 4 (Python), который переведён в режим поддержки; в Fedora 43 на DNF 5 перешёл и установщик Anaconda. Ключевое отличие от APT: DNF поддерживает транзакции с автоматическим rollback через RPM transaction API. При неудачной транзакции система возвращается в предыдущее состояние.

dnf install nginx
dnf remove nginx
dnf upgrade                    # обновить все пакеты
dnf search "web server"
dnf provides /usr/bin/curl     # какой пакет содержит файл
dnf history                    # история транзакций
dnf history undo 15            # откатить транзакцию

Модули (Modularity) — механизм RHEL/Fedora для параллельной доставки нескольких версий одного софта (например, Node.js 18 и 20). На практике модулярность оказалась слишком сложной и в Fedora 39+ от неё отказались. В RHEL 9 она остаётся, но с сокращённым scope.

Репозитории

rpm-репозитории используют repodata/ (XML-метаданные, сжатые gzip/zstd). Конфигурация в /etc/yum.repos.d/*.repo. RHEL использует subscription-manager для доступа к репозиториям; Fedora и CentOS Stream — открытые зеркала.

pacman (Arch Linux)

pacman уникален тем, что объединяет оба уровня — и low-level установку, и repository management — в одном инструменте. Формат пакета .pkg.tar.zst — просто tar-архив со сжатием zstd + метаданные в .PKGINFO и .BUILDINFO.

Философия Arch: rolling release, минимальный патчинг upstream-кода, PKGBUILD (bash-скрипт для сборки) как единственный source-файл. AUR (Arch User Repository) — community-репозиторий PKGBUILD'ов (не бинарных пакетов), собираемых пользователем через makepkg или AUR-хелперы (yay, paru). С pacman 7.0 (сентябрь 2024) скачивание пакетов выполняется от отдельного пользователя с урезанными правами, поэтому локальные репозитории приходится открывать группе alpm.

pacman -Syu                    # sync + upgrade (всегда вместе!)
pacman -S nginx                # установить
pacman -Rs nginx               # удалить с ненужными зависимостями
pacman -Ss "web server"        # поиск
pacman -Qi nginx               # информация об установленном пакете
pacman -Ql nginx               # файлы пакета
pacman -Fy                     # обновить файловую базу (нужно перед -F)
pacman -F /usr/bin/curl        # какой пакет содержит файл

Trade-off: partial upgrades в Arch не поддерживаются. pacman -Sy package (sync без upgrade) может сломать систему, так как новый пакет может зависеть от новых версий библиотек. Всегда pacman -Syu.

Универсальные форматы: Flatpak, Snap, AppImage

Все три решают одну проблему: кросс-дистрибутивная доставка приложений с bundled-зависимостями. Но архитектурно они сильно отличаются.

Flatpak

Разработан Red Hat/GNOME/Freedesktop. Ориентирован на десктопные приложения. Архитектура основана на OSTree (content-addressed хранилище, аналогичное git для бинарных файлов) и shared runtimes (org.gnome.Platform, org.kde.Platform, org.freedesktop.Platform). Приложения работают в sandbox через Bubblewrap (user namespaces + seccomp), доступ к ресурсам контролируется через XDG Portals.

Shared runtimes — ключевое архитектурное решение: вместо bundling всех зависимостей в каждое приложение, Flatpak использует общие runtime-образы. Десять GNOME-приложений разделяют один org.gnome.Platform, что экономит место по сравнению с Snap (где каждый пакет полностью самодостаточен). Flathub — основной репозиторий, но Flatpak децентрализован: можно добавлять свои remote-источники.

flatpak install flathub org.mozilla.firefox
flatpak run org.mozilla.firefox
flatpak update
flatpak list --app                # установленные приложения
flatpak override --user org.mozilla.firefox --filesystem=~/Downloads  # разрешить доступ

Flatseal — GUI для управления permissions (альтернатива flatpak override).

Snap

Разработан Canonical. Snap — SquashFS-образ, монтируемый read-only через loop device. snapd (фоновый демон) управляет lifecycle, confinement (AppArmor + seccomp) и обновлениями. Snap Store — единственный официальный репозиторий, и он проприетарный — главная точка критики. Snap использует каналы (stable, candidate, beta, edge) для доставки разных уровней стабильности.

Snap применяется не только для десктопных приложений: snapd управляет серверным софтом, IoT-устройствами (Ubuntu Core целиком построен на snap'ах). Автоматические обновления принудительны (можно отложить, но не отключить полностью).

Основная техническая проблема: startup time. Каждый snap — loop-mounted SquashFS, что добавляет latency при запуске. На системе с 10+ snap'ами это заметно при загрузке (каждый snap — отдельный mount point в выводе df).

AppImage

Полная противоположность: один файл, chmod +x, запуск. Нет демона, нет runtime, нет репозитория, нет sandboxing (по умолчанию). Внутри — FUSE-mounted SquashFS или ISO. Приложение запускается с правами пользователя и имеет полный доступ к системе.

AppImage идеален для: переносимых утилит (на флешке), тестирования разных версий приложения, ситуаций где нет root-доступа. Недостатки: нет автообновлений (есть AppImageUpdate, но это opt-in), нет sandbox, нет централизованного аудита безопасности.

Когда что использовать

Нативные пакеты (deb/rpm) — системный софт, серверные приложения, библиотеки, всё что критично для совместимости и безопасности. Обновления безопасности приходят быстрее (shared library обновляется один раз, а не в каждом контейнере).

Flatpak — десктопные приложения от третьих сторон. Лучший баланс между изоляцией и интеграцией с рабочим столом. Shared runtimes экономят место. Рекомендуемый формат для десктопа в 2025+.

Snap — Ubuntu-среды, IoT/embedded (Ubuntu Core), серверные приложения на Ubuntu. Если не на Ubuntu — overhead от snapd обычно не оправдан.

AppImage — портативность, одноразовое использование, окружения без root. Не для production-установок из-за отсутствия sandbox и обновлений.

Практика

# ---- deb/APT ----
apt list --installed                    # все установленные пакеты
apt policy nginx                        # из какого репозитория, приоритеты
apt-cache depends nginx                 # зависимости
apt-cache rdepends --installed nginx    # кто зависит от nginx
dpkg -L nginx                           # файлы пакета
dpkg -S /usr/bin/curl                   # какому пакету принадлежит файл
apt-mark hold nginx                     # запретить обновление

# Восстановление сломанного состояния
dpkg --configure -a                     # довести полуустановленные пакеты
apt --fix-broken install                # доустановить зависимости

# ---- rpm/DNF ----
rpm -qa                                 # все установленные пакеты
rpm -qi nginx                           # информация
rpm -ql nginx                           # файлы
rpm -qf /usr/bin/curl                   # какому пакету принадлежит файл
dnf repoquery --requires nginx          # зависимости
dnf repoquery --whatrequires nginx      # обратные зависимости

# ---- Общее: проверка целостности ----
dpkg --verify                           # deb: проверить файлы всех пакетов
rpm -Va                                 # rpm: то же самое
debsums -c                              # deb: альтернатива (пакет debsums)

Нюансы и trade-off'ы

Shared libraries vs bundled dependencies. Фундаментальный trade-off мира пакетов. Нативные пакеты разделяют библиотеки: одна libssl на всю систему. Обновление одной библиотеки закрывает уязвимость для всех зависящих приложений. Flatpak/Snap bundlят зависимости: каждое приложение получает свою копию. Это даёт isolation и стабильность, но означает, что security patch в libssl должен быть собран в каждый snap/flatpak отдельно. На практике это ведёт к задержкам в доставке security-обновлений.

apt upgrade vs apt full-upgrade. upgrade не удаляет пакеты (не разрешит конфликты, требующие удаления). full-upgrade (ранее dist-upgrade) может удалять пакеты для разрешения зависимостей. Для стабильных систем upgrade безопаснее; для перехода между релизами нужен full-upgrade.

RPM transaction rollback vs dpkg. RPM/DNF поддерживают rollback транзакций из коробки (dnf history undo). В deb-мире это долго было пробелом, который закрывали снаружи: snapper (с btrfs) для системы, etckeeper для конфигов. Пробел закрыт в apt 3.1 (октябрь 2025), где появились команды history-list, history-info, history-undo, history-redo и history-rollback, работающие поверх журнала транзакций apt. Функциональность свежая и в текущих stable-дистрибутивах может ещё отсутствовать, так что практическое преимущество RPM-стека пока сохраняется.

Pinning и приоритеты. APT позволяет через /etc/apt/preferences.d/ задавать приоритеты пакетов из разных репозиториев (apt_preferences(5)). DNF использует модули и versionlock plugin. Оба механизма критичны при использовании backports или третьесторонних репозиториев.

Snap и boot time. Каждый snap создаёт loop mount при загрузке. На Ubuntu Desktop с 10-15 snap'ами (включая snap-store, firefox, chromium, gnome-system-monitor) это добавляет заметные секунды к загрузке и засоряет mount / df вывод десятками squashfs-записей.

Linux Mint snapd в поставку не включает, но причина у него другая, и её стоит различать: в руководстве Mint названы централизованный контроль над единственным проприетарным магазином и то, что установка snap-пакета в Ubuntu могла происходить в обход apt — то есть модель управления, а не время загрузки.

Flatpak permissions. По умолчанию Flatpak-приложения не имеют доступа к домашней директории (кроме XDG-директорий через Portals). Это иногда вызывает проблемы: файловые менеджеры, IDE, терминалы нуждаются в широком доступе. Flatseal или flatpak override --filesystem=home решают это, но нарушают sandbox.

Gentoo portage заслуживает упоминания как радикально другая модель: source-based с USE flags, позволяющими собирать каждый пакет с нужным набором features. Максимальная гибкость, но время сборки измеряется часами. Binary packages (binpkg) значительно ускоряют этот процесс: с Portage 3.0.58 (декабрь 2023) форматом по умолчанию стал gpkg (GLEP 78), умеющий нести PGP-подпись, а с Portage 3.0.78 (май 2026) проверка подписи бинарных репозиториев включена по умолчанию — для старого формата xpak она не поддерживается вовсе.

Сравнение с FreeBSD

FreeBSD pkg — единый пакетный менеджер для всей системы (исключая base system, который обновляется через freebsd-update). Ports tree — единый source tree с Makefile'ами для сборки из исходников. Relationship аналогична Gentoo portage, но более зрелая и с лучшим tooling.

Ключевые отличия:

Base system vs packages. В FreeBSD граница чёткая: base system (ядро, утилиты, библиотеки) обновляется как единое целое. Пакеты — всё остальное. В Linux такого разделения нет: libc, coreutils, systemd — обычные пакеты, обновляемые независимо. Это даёт гибкость, но создаёт класс проблем (partial upgrade, ABI-несовместимость), невозможных в FreeBSD.

Единый менеджер. FreeBSD не имеет проблемы deb vs rpm vs pacman. Один формат, один инструмент, одно дерево портов. Нет нужды в «универсальных» форматах типа Flatpak.

Flavors и options. FreeBSD ports поддерживают options (аналог USE flags в Gentoo): при сборке из портов можно включить/отключить features. pkg (бинарные пакеты) используют default options. Это компромисс: бинарные пакеты быстрые, но без кастомизации; порты кастомизируемые, но медленные.

Jail-based isolation вместо Flatpak/Snap: в FreeBSD приложения изолируются через jails (см. статью 1), а не через bundled dependencies. Приложение внутри jail разделяет библиотеки base system, но изолировано на уровне ядра.

Источники

Связанные заметки

Из библиотеки института уносят только знания. Читателей здесь не считают: посещение не регистрируется, отметок в издании не остаётся, счётчиков нет ни у одного издания фонда.

Издание пополняется и пересверяется. Текст доступен на условиях CC BY-SA 4.0 — унесённое можно передавать дальше на тех же условиях.

Снять копию (.md) К каталогу фонда