--- tags: [linux, tooling] verified: 2026-09-02 --- # 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 прямо рекомендует ей воспользоваться после обновления: ```conf # Новый формат (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. При неудачной транзакции система возвращается в предыдущее состояние. ```bash 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`. ```bash 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-источники. ```bash 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 и обновлений. ## Практика ```bash # ---- 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, но изолировано на уровне ядра. ## Источники - [Debian Policy Manual, Chapter 7: Relationships](https://www.debian.org/doc/debian-policy/ch-relationships.html) — формальная спецификация зависимостей - [How Debian packaging works — Joyful Bikeshedding](https://www.joyfulbikeshedding.com/blog/2020-08-03-how-debian-packaging-works.html) — отличное введение в устройство .deb - [APT User's Guide](https://www.debian.org/doc/manuals/apt-guide/) — официальная документация APT - [DNF5 documentation](https://dnf5.readthedocs.io/) — документация актуального DNF 5 (документация DNF 4 осталась на dnf.readthedocs.io) - [RPM Packaging Guide](https://rpm-packaging-guide.github.io/) — руководство по созданию rpm-пакетов - [pacman — ArchWiki](https://wiki.archlinux.org/title/Pacman) — полное руководство по pacman - [Flatpak documentation](https://docs.flatpak.org/) — архитектура и API Flatpak - [Snapcraft documentation](https://snapcraft.io/docs) — документация Snap - [AppImage documentation](https://docs.appimage.org/) — формат и использование AppImage - [Linux Mint User Guide: Snap Store](https://linuxmint-user-guide.readthedocs.io/en/latest/snap.html) — позиция дистрибутива, отказавшегося от snap, и её причины из первых рук - FreeBSD Handbook: [Packages and Ports](https://docs.freebsd.org/en/books/handbook/ports/) — для сравнения --- ## Связанные заметки - [Linux — файловая иерархия и FHS](./linux-filesystem-hierarchy.md) — куда пакетный менеджер кладёт файлы - [Linux — контейнеризация](./linux-containerization.md) — Flatpak и Snap как изолированная доставка софта - [Nix Flakes](./archive/nixos-flakes.md) — декларативная и воспроизводимая альтернатива (архивная заметка) - [FreeBSD — pkg и Ports Collection](./freebsd-pkg-and-ports.md) — бинарные пакеты и сборка из портов, для сравнения - [Linux — сводный cheatsheet](./linux-map-cheatsheet.md) — быстрая справка по apt, dnf и pacman - [Домашний десктоп на CachyOS](./setups/cachyos-desktop/hyprland-desktop.md) — состав пакетов конкретной установки на pacman - [Debian: модель релизов и управление пакетами](./debian-releases-and-packages.md) — углубление deb-части: политика версий, deb822, backports и пиннинг