Будущая Stable.
На момент этой публикации это:
forky
В неё постепенно попадают пакеты из Unstable после выполнения определённых требований. Она содержит более свежие версии ПО, но ещё не прошла весь release-процесс Stable.
Unstable
Постоянно развивающаяся ветка:
sid
Именно здесь активно появляются новые версии пакетов и происходят изменения. Далее часть этих пакетов постепенно проходит путь:
unstable
↓
testing
↓
freeze
↓
stable
Это одна из ключевых причин, почему Debian Stable не ориентируется на постоянное получение самых новых upstream-релизов.
Что означает «Stable» на практике
После выпуска Debian Stable набор программного обеспечения становится в значительной степени фиксированным. Это не означает:
пакеты больше вообще не обновляются. Обновления продолжают выходить. Особенно:
- — исправления безопасности;
- — критичные исправления ошибок;
- — изменения, необходимые для нормальной эксплуатации.
Но основной принцип примерно такой:
минимум изменений
↓
минимум неожиданного поведения
В Stable стараются не менять систему просто потому, что upstream выпустил новую major-версию приложения.
Почему версия пакета может выглядеть старой
Представим, что в Stable находится:
software 5.2
Upstream уже выпустил:
6.0
В версии 5.2 обнаруживается уязвимость. На первый взгляд кажется логичным:
5.2 → 6.0
Но новая major-версия может изменить:
- — API;
- — ABI;
- — конфигурацию;
- — поведение;
- — зависимости;
- — формат данных.
Для production-системы это может создать новую проблему. Поэтому Debian часто использует другой подход:
5.2 + security patch
То есть нужное исправление переносится в существующую версию пакета. В результате номер upstream-версии может выглядеть старым, хотя известная уязвимость уже исправлена. Это важный момент:
старая upstream-версия
≠
пакет обязательно уязвим
Нужно смотреть именно Debian package revision и security advisory.
Вот где проявляется «консервативность» Debian
Для production-инфраструктуры предсказуемость иногда важнее новых возможностей. Например, у нас есть:
Nginx PostgreSQL PHP OpenSSH application
Система протестирована. Если каждый месяц один из компонентов получает новый major release, появляется дополнительная работа:
update ↓ compatibility testing ↓ config changes ↓ application testing ↓ possible rollback
Stable уменьшает частоту таких изменений. Это не означает: никогда ничего не обновлять. Это означает:
изменения происходят более контролируемо.
А если нужен более новый пакет?
Для этого существует Debian Backports. Идея:
пакет из Testing
↓
пересобран для Stable
↓
trixie-backports
Например, администратору нужен более новый kernel или другая версия конкретного программного обеспечения. Не обязательно переводить всю систему на Testing. Можно использовать backport только для нужного пакета. Это важный принцип. Не:
Stable слишком старый → подключаем всё из Testing
а:
Stable + точечно выбранный backport
Сам Debian рекомендует использовать Backports именно избирательно. Потому что пакеты оттуда не проходят абсолютно тот же уровень комплексного тестирования, что основная Stable.
Point release — это не новая версия Debian
Например:
13.6 → 13.7
может выглядеть как полноценный upgrade ОС. Но в модели Debian point release — прежде всего обновлённый снимок Stable. В него собираются накопившиеся:
- — security fixes;
- — серьёзные bug fixes;
- — обновления installation media.
То есть существующий актуально обновляемый Debian 13 не требуется «переустанавливать на 13.7». Обычный:
apt update apt upgrade
доводит систему до актуального состояния репозитория. Новый номер point release особенно важен для свежих установочных образов.
Срок поддержки
Для Debian 13 жизненный цикл разделён примерно так:
2025 release ↓ 2028 окончание основной поддержки ↓ 2030 окончание LTS
То есть суммарно ветка получает около пяти лет сопровождения. Для инфраструктуры это позволяет строить достаточно длинный жизненный цикл сервера без необходимости ежегодно выполнять major upgrade ОС. Но нужно учитывать: во время LTS набор поддерживаемых архитектур может быть меньше первоначального.