---
tags: [linux, tooling]
verified: 2026-09-02
---

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

## Обзор

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

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

[Пакетные менеджеры](./linux-package-managers.md) покрывают `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/`:

```conf
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 появилась отдельная команда:

```bash
apt modernize-sources
```

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

### Компоненты

| Компонент | Что внутри |
|---|---|
| `main` | свободное ПО, зависящее только от `main` — собственно Debian |
| `contrib` | свободное, но зависящее от несвободного |
| `non-free` | несвободное ПО |
| `non-free-firmware` | несвободные прошивки, выделенные из `non-free` в Debian 12 |

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

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

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

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

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

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

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

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

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

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

```conf
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 безопасно, система от этого не поедет. Взять пакет нужно явно:

```bash
apt install -t trixie-backports nginx
```

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

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

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

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

### apt и apt-get

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

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

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

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

### update, upgrade, full-upgrade

| Команда | Что делает |
|---|---|
| `apt update` | обновляет списки пакетов; ничего не устанавливает |
| `apt upgrade` | обновляет установленные пакеты, может установить новые ради зависимостей, но не удаляет |
| `apt upgrade --without-new-pkgs` | то же, но и новых не ставит — самый консервативный вариант |
| `apt 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 именно меняет.

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

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

Первый — потому что внезапная перезагрузка сервера в три часа ночи может оказаться дороже, чем отложенное применение обновления ядра. Второй закрывает [переполнение `/boot`](./system-recovery.md) — типичную аварию на машинах, которые долго обновлялись автоматически.

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

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

```text
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 углублённо](./ssh-advanced.md) — там же оговорка, что `Include` должен стоять в начале файла). Для пакетов с `debconf` предпочтителен `dpkg-reconfigure`, а не ручная правка.

### Диагностика

```bash
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

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

| | Frozen (Debian stable) | Rolling (Arch) |
|---|---|---|
| Версии | старые, предсказуемые | свежие |
| Что ломается | ничего, пока не мигрируешь | отдельное обновление, внезапно |
| Когда ломается | в момент перехода между релизами, планово | в любой момент, непланово |
| Требуемое внимание | раз в два года, много | постоянно, понемногу |
| Откат | точечных обновлений почти не нужен | нужен регулярно, отсюда снепшоты |

У заморозки проблема — старый софт и разовая большая миграция. У 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, полный бэкап — что-то из этого обязательно (см. [резервное копирование](./backup-strategy.md)).
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`, чтобы разрыв соединения не убил процесс на середине; правильно — иметь доступ к консоли хостера, как описано в [восстановлении незагружающейся системы](./system-recovery.md).

## Сравнение с FreeBSD

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

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

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

## Источники

- [Debian Releases](https://www.debian.org/releases/) — ветки, кодовые имена, сроки поддержки
- [Debian 13 release notes](https://www.debian.org/releases/trixie/releasenotes) — миграция источников в deb822, `apt modernize-sources`, порядок перехода
- [sources.list(5)](https://github.com/Debian/apt/blob/main/doc/sources.list.5.xml) — формат deb822, статус однострочного формата и срок его удаления
- [apt_preferences(5)](https://github.com/Debian/apt/blob/main/doc/apt_preferences.5.xml) — приоритеты 100/500/990, `NotAutomatic` и `ButAutomaticUpgrades`
- [Debian Backports](https://backports.debian.org/) — что и как попадает в backports
- [Debian LTS](https://wiki.debian.org/LTS) — объём и сроки расширенной поддержки
- [Debian Security Tracker](https://security-tracker.debian.org/) — состояние уязвимости в конкретном пакете и релизе

---

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

- [Linux — пакетные менеджеры](./linux-package-managers.md) — deb в ряду других моделей доставки; эта статья углубляет deb-часть
- [Linux — файловая иерархия и FHS](./linux-filesystem-hierarchy.md) — куда пакеты раскладывают файлы и почему `/usr/local` не их территория
- [Linux — обновление и управление загрузкой](./linux-boot-management.md) — ядра, `/boot` и снепшот перед переходом между релизами
- [Обратный прокси и TLS](./reverse-proxy-tls.md) — пример, где версия пакета в дистрибутиве меняет рекомендацию, а не только команду
- [Восстановление незагружающейся системы](./system-recovery.md) — переполненный `/boot` и доступ к консоли при обновлении по сети
- [FreeBSD — pkg и Ports Collection](./freebsd-pkg-and-ports.md) — `quarterly` против `latest` и разделение базы и пакетов