Debian: модель релизов и управление пакетами

Обзор

Цикл статей о Linux сознательно не привязан к дистрибутиву, и это правильно: ядро, syscalls и /proc одинаковы везде. Но у дистрибутива есть собственное устройство, которое к ядру не сводится, — модель релизов, политика версий, формат репозиториев, механика обновления. Это и определяет, что вы реально получите, установив пакет.

Debian здесь — эталонный представитель «замороженного» подхода, и разбирать его интереснее всего именно в противопоставлении rolling-модели. Практическая ценность не теоретическая: почти любая статья про софт рано или поздно упирается в вопрос «а что из этого есть в дистрибутиве и насколько оно старое». Пример из обратного прокси и TLS: встроенный ACME-модуль nginx требует версии 1.29.0, в стабильном Debian лежит 1.26.3, и это меняет не пример в статье, а саму рекомендацию.

Пакетные менеджеры покрывают dpkg и apt как один из вариантов в ряду с rpm и pacman. Здесь — то, чего там нет: политика релизов и работа с версиями.

Версии-якоря: Debian 13 «trixie» — текущий стабильный релиз (вышел 9 августа 2025, последнее точечное обновление на момент написания — 13.6 от 11 июля 2026); Debian 14 «forky» в testing; apt 3.0 в stable, 3.3 в unstable.

Модель релизов

Четыре ветки и движение пакета по ним

Ветвей четыре, и они не «стадии качества», а разные наборы с разными правилами.

unstable (sid) — сюда мейнтейнер загружает новую версию пакета. Имя постоянное: sid не выпускается и никогда не становится stable, он просто всегда есть.

testing — пакет переезжает из unstable автоматически, если выполнены условия: провёл в unstable определённый срок (обычно от двух до десяти дней в зависимости от срочности), собрался на всех архитектурах, не имеет новых критичных ошибок и не ломает зависимости других пакетов в testing. Это ключевой механизм: переход не решение человека, а результат проверки.

stable — testing, замороженный и выпущенный. В момент релиза testing получает кодовое имя и становится stable; следом заводится новый testing со следующим именем.

experimental — не ветка, а свалка для заведомо ломающего: сюда кладут то, что нельзя пускать даже в unstable. Автоматически оттуда ничего не ставится.

Отсюда неочевидное: testing — не «бета стабильного», а постоянно движущаяся система, у которой хуже всех обстоят дела с безопасностью. Исправления уязвимостей попадают сначала в unstable и потом переезжают по общим правилам, тогда как у stable есть отдельный поток security с прямой доставкой. Для повседневной рабочей машины testing бывает разумен, для сервера — плохой выбор именно по этой причине, а не из-за нестабильности.

Что означает заморозка

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

Это выглядит как недостаток, а является контрактом. Заморозка означает, что система, работавшая вчера, будет работать завтра, и что обновление безопасности не принесёт с собой изменения поведения. Именно поэтому в stable «старый софт»: не потому, что не успели, а потому, что подъём версии нарушил бы то, ради чего эту ветку выбирают.

Отсюда правильный способ читать номера версий в Debian. 1.26.3-3+deb13u2 — это upstream-версия 1.26.3, третья ревизия пакета Debian, вторая правка внутри trixie. Обновления безопасности меняют суффикс, а не upstream-часть, и поэтому сравнивать версию в дистрибутиве со списком уязвимостей по номеру upstream бесполезно: исправление уже может быть внесено обратным портированием, а номер остаться прежним. Проверять нужно через трекер безопасности Debian или apt changelog, а не по номеру.

Сроки поддержки

Пять лет, разделённые на две части: три года полной поддержки командой безопасности Debian, затем два года LTS, который ведёт отдельная команда с более узким охватом архитектур и пакетов. Для trixie это 9 августа 2028 и 30 июня 2030 соответственно.

Дальше существует коммерческий ELTS от Freexian, но полагаться на него как на «Debian ещё поддерживается» не стоит — это внешняя услуга с другим объёмом.

Планировать переезд на следующий релиз разумно в первый год после его выхода: к этому моменту закрыты худшие сюрпризы, а до конца полной поддержки текущего ещё далеко. Ждать до последнего месяца LTS — способ обнаружить, что миграция сложнее, чем казалось, и что времени нет.

Репозитории

Формат deb822

Однострочный sources.list объявлен устаревшим. Документация apt формулирует это прямо: формат считается deprecated и «может быть в итоге удалён, но не ранее 2029 года». Новый формат — файлы .sources в /etc/apt/sources.list.d/:

Types: deb
URIs: https://deb.debian.org/debian
Suites: trixie trixie-updates
Components: main contrib non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.pgp

Types: deb
URIs: https://security.debian.org/debian-security
Suites: trixie-security
Components: main contrib non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.pgp

Выигрыш не косметический. Signed-By привязывает ключ к конкретному источнику — в однострочном формате ключ, положенный в общий доверенный набор, подписывал что угодно, включая репозитории, для которых он не предназначался. Плюс формат допускает несколько значений в поле и комментарии к каждому источнику. На расширение стоит обратить внимание: с trixie канонические имена файлов ключниц — .pgp, а привычные .gpg оставлены символическими ссылками ради совместимости и со временем исчезнут.

Для перехода в apt появилась отдельная команда:

apt modernize-sources

Она переписывает существующие .list в .sources, сохраняя старые файлы. Release notes trixie рекомендуют свести всё к одному debian.sources.

Компоненты

Выделение прошивок в отдельный компонент — прагматичное решение конкретной проблемы: без несвободных прошивок не работает половина Wi-Fi-адаптеров и видеокарт, и требовать ради этого подключения всего non-free было неудобно. Установщик с Debian 12 подключает non-free-firmware по умолчанию.

security и updates — оба нужны

Два разных потока, которые постоянно путают.

trixie-security — исправления уязвимостей. Доставляются быстро, с отдельной инфраструктуры, ради скорости в обход обычного цикла.

trixie-updates — то, что не является уязвимостью, но не может ждать следующего точечного релиза: сломавшиеся из-за внешних изменений пакеты, обновления часовых поясов и антивирусных сигнатур.

Нужны оба. Без security система не получает исправлений уязвимостей — это очевидно; без updates она в какой-то момент оказывается с устаревшей tzdata и неверным локальным временем (см. время и синхронизацию).

Отдельно trixie-backports — свежие версии, собранные для stable. Подключаются, но не используются автоматически, и механика этого разбирается ниже.

Сторонние репозитории

Подключаются со своим ключом, положенным отдельно, а не в общий набор. Каталогов для этого два, и документация apt разводит их по владельцу: /usr/share/keyrings — для ключниц, которые приносят пакеты, /etc/apt/keyrings — для тех, что кладёт администратор:

curl -fsSL https://example.com/gpg | \
  gpg --dearmor | sudo tee /etc/apt/keyrings/example.gpg > /dev/null

Types: deb
URIs: https://example.com/debian
Suites: trixie
Components: main
Signed-By: /etc/apt/keyrings/example.gpg

Способ apt-key add, который встречается во всех старых инструкциях, устарел и удалён: он клал ключ в набор, доверяющий всем репозиториям сразу.

Цену подключения стоит проговорить явно, потому что о ней обычно не думают. Пакет из стороннего репозитория выпадает из-под обновлений безопасности Debian — за него отвечает тот, кто его собрал, ровно настолько, насколько ему хочется. Вы получаете свежую версию и берёте на себя слежение за уязвимостями в ней. Для одного-двух пакетов, где это осознанное решение, нормально; для десятка — это уже другой дистрибутив, собранный вручную и без чьей-либо гарантии.

Пиннинг: как не собрать франкенштейна

Механизм приоритетов (apt_preferences) — то, чем backports и сторонние источники удерживаются в рамках.

По умолчанию apt раздаёт приоритеты так: 100 — установленным версиям, 500 — доступным, но не установленным, 990 — версиям из целевого релиза, если он задан. Правило разрешения простое: берётся версия с наибольшим приоритетом, а понижение версии не происходит, пока приоритет не превысит 1000.

Самое полезное следствие относится к backports и объясняет их поведение, которое иначе выглядит загадочным. Репозиторий backports помечен в своём Release-файле как NotAutomatic: yes вместе с ButAutomaticUpgrades: yes. Первое даёт приоритет 1 — то есть оттуда ничего не поставится само. Второе поднимает приоритет до 100 для пакетов, которые уже установлены из backports, — то есть однажды взятое оттуда будет обновляться оттуда же.

Практически это означает: подключить backports безопасно, система от этого не поедет. Взять пакет нужно явно:

apt install -t trixie-backports nginx

Собственный пиннинг пишется в /etc/apt/preferences.d/:

Package: *
Pin: release n=trixie-backports
Pin-Priority: 100

Главное предостережение: пиннинг репозитория от другого релиза (например, подтягивание отдельных пакетов из testing в stable) почти всегда заканчивается плохо. Пакет тянет зависимости, зависимости тянут libc, и система оказывается смешанной без возможности вернуться. Если из stable нужен пакет, которого там нет: сначала backports, потом контейнер или Flatpak, потом сторонний репозиторий — и только в самом крайнем случае пакеты из другой ветки.

Практика эксплуатации

apt и apt-get

apt — интерфейс для человека: прогресс-бары, цвет, разумные умолчания. apt-get и apt-cache — стабильный интерфейс для скриптов.

Разница не стилистическая, и apt сам о ней сообщает при запуске из скрипта:

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

Формат вывода и поведение apt меняются между версиями намеренно, потому что это интерфейс пользователя. В скриптах и Ansible-плейбуках нужен apt-get.

update, upgrade, full-upgrade

full-upgrade (прежнее имя dist-upgrade) опасен ровно тем, что делает: он может удалить пакет, если иначе зависимости не сходятся. Внутри стабильного релиза это почти никогда не требуется, и запускать его по привычке не нужно. Обязателен он при переходе между релизами, где перестановка зависимостей — норма.

Правило простое: внутри релиза — apt upgrade; при переходе между релизами — сначала apt upgrade --without-new-pkgs, потом apt full-upgrade. Причём читать список того, что предлагается удалить, — обязательный шаг, а не формальность.

unattended-upgrades

Автоматическая установка обновлений. Умолчание разумное: в Origins-Pattern включены поток security и сам стабильный архив, то есть исправления, приезжающие с точечными релизами, а строки про -updates, -proposed-updates и backports оставлены закомментированными.

Расширять его до полного updates можно, но осторожно, а тянуть автоматически backports или сторонние репозитории — не нужно точно: смысл автоматики в том, что она не меняет поведение системы, а backports именно меняет.

Два параметра, которые стоит настроить осознанно:

Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";

Первый — потому что внезапная перезагрузка сервера в три часа ночи может оказаться дороже, чем отложенное применение обновления ядра. Второй закрывает переполнение /boot — типичную аварию на машинах, которые долго обновлялись автоматически.

Конфликты конфигов при обновлении

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

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?

Варианты: Y — взять версию из пакета (ваши правки уходят в .dpkg-old), N — оставить свою (новая ложится рядом как .dpkg-dist), D — показать diff, Z — уйти в оболочку и разобраться.

Правильный ответ почти всегда D, а затем осознанное решение. Опасность обоих автоматических вариантов симметрична: взяв пакетную версию, вы теряете настройку и, например, снова разрешаете вход root по SSH; оставив свою, вы не получаете новых умолчаний, которые могли быть исправлением безопасности.

Механизм ucf (Update Configuration File) делает то же самое для конфигов, которые пакет генерирует, а не поставляет напрямую, — вопрос выглядит похоже.

Профилактика — не править файлы, у которых есть каталог .d. Настройка в /etc/ssh/sshd_config.d/99-local.conf не конфликтует при обновлении вообще (см. SSH углублённо — там же оговорка, что Include должен стоять в начале файла). Для пакетов с debconf предпочтителен dpkg-reconfigure, а не ручная правка.

Диагностика

apt policy nginx              # какая версия установлена, какие доступны, из каких источников
apt-cache madison nginx       # все версии во всех подключённых источниках
apt list --upgradable         # что готово обновиться

dpkg -L nginx                 # какие файлы принёс пакет
dpkg -S /etc/nginx/nginx.conf # какому пакету принадлежит файл
dpkg -l | grep ^rc            # удалённые пакеты с оставшимися конфигами

apt-file search bin/htpasswd  # в каком пакете лежит файл — включая неустановленные

apt policy — первое, что нужно запускать при любом вопросе «почему ставится не та версия»: он показывает приоритеты источников и сразу объясняет выбор apt. apt-file требует установки и apt-file update, но это единственный способ узнать, какой пакет поставить ради нужной команды.

Свежие версии apt добавляют к этому два инструмента, которых в trixie с её apt 3.0 ещё нет: в 3.1 появились apt why и apt why-not, показывающие трассу решателя, а в ветке 3.2 — журнал операций с откатом (apt history-list, apt history-undo, apt history-rollback).

Строки rc в выводе dpkg -l — пакеты, удалённые без purge, чьи конфиги остались. Обычно безвредно, но при повторной установке даёт неожиданное: пакет подхватывает старую конфигурацию.

Заморозка против rolling

Два подхода порождают два непересекающихся набора проблем, и «лучше» здесь не существует.

У заморозки проблема — старый софт и разовая большая миграция. У rolling — необходимость быть готовым чинить в любой момент, откуда и практика снепшотов перед каждым обновлением, стандартная для Arch и openSUSE Tumbleweed и почти не нужная в Debian stable.

Отсюда практический вывод про перенос рецептов. Arch Wiki — лучшая документация по Linux, и она же источник тонких ошибок при использовании на Debian: там описано поведение свежих версий. Совет, опирающийся на возможность, появившуюся в последнем релизе программы, на stable просто не работает, и симптом при этом выглядит как ошибка конфигурации, а не как отсутствие функции. Первое, что стоит делать, перенося рецепт, — сверить версию: apt policy <пакет>.

Две структурные особенности, которые тоже мешают переносу:

Разбиение пакетов. Debian делит upstream-проект на -dev (заголовки для сборки), -common (архитектурно-независимые данные), -doc, иногда отдельные модули. Инструкция «поставьте libfoo» на Debian означает libfoo для запуска и libfoo-dev для сборки, и отсутствие второго даёт ошибку компиляции, которая никак не намекает на причину.

Нет AUR. Аналога пользовательского репозитория рецептов сборки в Debian нет. Заменяют его backports (официально, для части пакетов), сторонние репозитории проектов, контейнеры и Flatpak, а в крайнем случае — сборка своего пакета через dpkg-buildpackage. Ни один из путей не так удобен, как AUR, и это осознанный размен: в Debian нет и класса проблем, порождаемого AUR.

Когда что выбирать. Сервер, который должен работать без внимания, — заморозка. Рабочая станция, где нужны свежие инструменты и вы готовы чинить, — rolling. Смешанный вариант, который работает лучше всего на практике: Debian stable как основа плюс контейнеры или Flatpak для того немногого, что обязано быть свежим. Это даёт свежесть там, где она нужна, не размывая базу.

Переход на следующий релиз

Порядок отработан и отклоняться от него не стоит.

1. Прочитать release notes. Не пролистать — прочитать раздел про несовместимости. Это единственный документ, где перечислено, что именно сломается.
2. Снепшот или бэкап. Boot environment, снепшот Btrfs или LVM, полный бэкап — что-то из этого обязательно (см. резервное копирование).
3. Обновиться полностью в текущем релизе. Переход из неполностью обновлённой системы — источник лишних конфликтов.
4. Проверить, что нет посторонних пакетов. apt list '?narrow(?installed, ?not(?origin(Debian)))' либо aptitude search '~i!~ODebian' — всё, что не из Debian, при переходе поведёт себя непредсказуемо и подлежит рассмотрению заранее.
5. Поправить источники на новое имя релиза; при переходе на trixie — заодно перевести их в deb822 через apt modernize-sources.
6. Двумя шагами: сначала apt upgrade --without-new-pkgs, потом apt full-upgrade. Первый шаг обновляет то, что обновляется без перестановки, уменьшая объём работы для второго.
7. Перезагрузиться и проверить. Юниты (systemctl --failed), сервисы, оставшиеся .dpkg-dist (find /etc -name '*.dpkg-*').

Выполнять это по SSH без доступа к консоли — плохая идея: обновление перезапускает сеть и sshd. Минимум — запуск внутри tmux или screen, чтобы разрыв соединения не убил процесс на середине; правильно — иметь доступ к консоли хостера, как описано в восстановлении незагружающейся системы.

Сравнение с FreeBSD

Разделение, которого в Debian нет: во FreeBSD базовая система и стороннее ПО обновляются разными инструментами и живут по разным правилам. freebsd-update ведёт базу, pkg — пакеты из портов, и версии в них не связаны.

Практическое следствие в том, что вопрос «замороженный или rolling» во FreeBSD распадается на два независимых. База консервативна и привязана к релизу; ветка latest в pkg по свежести ближе к rolling, а quarterly даёт заморозку на квартал. То есть можно иметь стабильную базу и свежий прикладной софт, не смешивая репозитории и не занимаясь пиннингом, — в Debian аналог этого приходится изображать контейнерами.

Схожего тоже много: quarterly и latest — примерно то же противопоставление, что stable и testing, а построение пакета из портов со своими опциями — близкий аналог dpkg-buildpackage, только с человеческим интерфейсом. Подробнее — в pkg и Ports.

Источники

• Debian Releases — ветки, кодовые имена, сроки поддержки
• Debian 13 release notes — миграция источников в deb822, apt modernize-sources, порядок перехода
• sources.list(5) — формат deb822, статус однострочного формата и срок его удаления
• apt_preferences(5) — приоритеты 100/500/990, NotAutomatic и ButAutomaticUpgrades
• Debian Backports — что и как попадает в backports
• Debian LTS — объём и сроки расширенной поддержки
• Debian Security Tracker — состояние уязвимости в конкретном пакете и релизе

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

• Linux — пакетные менеджеры — deb в ряду других моделей доставки; эта статья углубляет deb-часть
• Linux — файловая иерархия и FHS — куда пакеты раскладывают файлы и почему /usr/local не их территория
• Linux — обновление и управление загрузкой — ядра, /boot и снепшот перед переходом между релизами
• Обратный прокси и TLS — пример, где версия пакета в дистрибутиве меняет рекомендацию, а не только команду
• Восстановление незагружающейся системы — переполненный /boot и доступ к консоли при обновлении по сети
• FreeBSD — pkg и Ports Collection — quarterly против latest и разделение базы и пакетов