Debian 常被称作保守的 Linux 发行版。这个说法有用，只是遮住了更值得阅读的工程信号。Debian 真正的产品，是一份归档契约：社会文件、授权结构、包维护实践、迁移规则、发布冻结、架构取舍，以及贡献者线下协作，共同把一个庞大的志愿者项目转化为用户可以安装的 stable。[1][2][3][4][5][6][7]
在 2026 年，这份契约的意义更清楚，因为 Debian 13 "trixie" 已经进入现实发布周期。Debian 发布页把 13.4 列为 2026 年 3 月 14 日的 trixie 当前点版本，并注明 13.0 最初于 2025 年 8 月 9 日发布。[3] 同一页面给出支持期限：完整 Debian 支持持续到 2028 年 8 月 9 日，随后进入长期支持，到 2030 年 6 月 30 日结束。[3] 对平台团队来说，这就是 Debian 的实际承诺。它提供的是一条可读的序列：冻结、发布、点更新、安全维护，以及最终收窄的 LTS 阶段。
13.0 发布时的数字展示了问题规模。Debian 说 trixie 经历了 2 年 1 个月 30 天的开发，包含 69,830 个包，新增超过 14,100 个包，移除超过 8,840 个过时包，更新 44,326 个包，整体安装内容约 403 GB，代码行数超过 14.6 亿。[4] Phoronix 的独立发布读解，则把同一版本放在 Linux 6.12 LTS、GNOME 48、GCC 14.2、Python 3.13、官方 64 位 RISC-V 支持、HTTP Boot、完成 64 位 time_t ABI 过渡，以及进一步的可复现构建工作这些节点上展开。[8] 这些细节超出规格表层面的展示，说明 Debian 治理必须比任何单一上游项目的发布流程更慢，也更明确。
配图说明：题图使用 Wikimedia Commons 上一张真实的 DebConf15 海德堡合影。它作为社区档案照片，避开标志或图表式表达，因为本文的重点在于，Debian 的发布可靠性来自人、会议、受托角色与维护规范，与工具链同样相关。[9]
基础文件把范围放在明处
Debian 的《社会契约》是第一层治理信号。2022 年批准的 1.2 版写明，Debian 将保持 100% 自由，并以 Debian 自由软件指导原则作为判断 Debian 系统组成部分的标准。[1] 它也画出熟悉的归档边界：contrib 与 non-free 可以得到 Debian 基础设施支持，但其中包属于 Debian 系统之外；当硬件需要固件时，官方介质可以包含原本属于 Debian 系统之外的固件。[1]
这一区分常被看成旧时代语言，可一旦采购或合规团队需要定义自己到底安装了什么，它的分量就显出来了。Debian 的价值落在提前暴露边界这件事上。核心系统、contrib、non-free 与固件处理，连接到一份可以在审计、衍生发行版与内部平台标准中引用的公开基础文件。[1]
《宪章》是第二层信号。它把 Debian 描述为一群个人为创建自由操作系统而形成的共同体，并列出谁可以作决定：通过一般决议或选举行动的开发者、项目领导人、技术委员会、负责自身任务的个体开发者、由项目领导人任命的受托人，以及项目秘书。[2] 它还写下一条对志愿者持续性极为重要的规则：宪章不强迫任何人为项目工作。[2]
这两点解释了 Debian 性格中许多看似缓慢的部分。维护者对自己的工作拥有真实的本地权力，同时 Debian 又为全项目问题、技术争议、授权职责与基础文件保留宪章机制。[2] 这个系统有意抵抗一个人式产品管理。这样的抵抗会让急躁用户感到费力，却也让项目在领导层轮替、厂商压力与大型技术迁移中存续下来，不至于把每一次冲突都交给创始人式决定。
发布列车由关口构成，而并非由气氛构成
trixie 冻结政策把 Debian 的发布纪律写得很具体。软冻结从 2025 年 4 月 15 日开始，trixie 变更被限制在小而有目标的修复里，testing 迁移延迟增加到 10 天，并且不允许尚未在 trixie 中的包进入该版本。[5] 2025 年 5 月 15 日，关键包与缺少 autopkgtest 的包进入更硬的规则，需要发布团队审查；带有非平凡 autopkgtest 的非关键包，仍可在 20 天延迟后自动迁移。[5] 完全冻结从 2025 年 7 月 27 日开始，此后包只有经过发布团队人工审查才能迁移。[5]
这就是 Debian stable 的操作核心。stable 在这里指向一串逐渐收紧的准入规则。新包停止进入。迁移延迟拉长。关键包接受人工审查。变更需要变成有目标的内容：发布关键修复、重要缺陷、翻译与文档修复、发布流程相关更新，以及有充分理由的 unblock 请求。[5]
从采用角度看，重要教训在于，Debian 的发布周期不只是一两年一次的日期。它把 unstable 流转化为 testing 候选，再主动降低熵，直到归档可以被宣告为 stable。把 Debian 只理解成“包更旧”的团队，会错过要点。包的年龄，是更大发布契约的副产品：当归档接近发布，任何变更都必须面对整体系统，而不只面对某一个维护者的包。
Britney 让归档成为受测试的依赖图
迁移层给这份契约提供机器。britney 文档写到，它的工作是在 Debian unstable 这样的源套件中，半自动选择已经准备好迁移到 Debian testing 这样的目标套件的迁移项。[6] 候选项必须通过目标套件的政策，核心是避免在 QA 检查上造成回归，同时迁移结果不能让可安装性倒退。[6] 对通过政策检查的项目，britney 还会执行成本更高的可安装性测试，包括二进制包在特定架构上变得不可安装时产生的后果。[6]
这个机制解释了 Debian 为什么可以同时保持分散与一致。维护者上传包，但上传行为本身无法直接把包送入下一次 stable 发布。包必须穿过一个理解图结构的关口，错误、测试、依赖、构建状态、回归与不可安装性会在这里彼此作用。[6] 到冻结阶段，这些关口变得更严格，也更依赖人工审查。[5][6]
对操作者来说，实践信号很直白。Debian 归档是一张带有政策记忆、经过测试的依赖图，超出上游 tarball 集合。代价是延迟：新的上游版本会等待，一些包会错过发布。收益是，发行版能够在架构、包关系、升级路径与安全支持窗口之间作出整体承诺。[3][4][5][6]
架构政策也是维护的一部分
trixie 还显示 Debian 治理包含拒绝。发布页列出初始支持架构：amd64、arm64、armhf、ppc64el、riscv64 与 s390x；i386 只作为 amd64 上运行 32 位软件的协同架构获得支持，armel 只支持升级，不支持新安装。[3] 发布公告说得更直接：i386 不再是带官方内核与安装器的常规架构，armel 也将停在最后一个发布周期。[4]
这属于维护预算层面的判断。每一个架构都会带来构建基础设施、移植工作、工具链暴露面、安全响应、安装器行为与包依赖图后果。加入官方 64 位 RISC-V 支持，同时把旧路径降级，是治理选择，超出硬件注记。[3][4][8]
由此展开的判断是，Debian 稳定性既依赖新增承诺，也依赖减少不再可靠的承诺。一个平台若拒绝退役任何架构、安装路径或包表面，最终会把维护预算花在假装上。Debian 的公开发布说明让取舍变得可检查：新的 RISC-V 支持进入 stable 集合，i386 与 armel 则进入更窄的位置。[3][4][8]
DebConf 是维护基础设施
DebConf 很容易被看成社区装饰。Debian 自己对 DebConf25 的收尾说明，则让它更像维护基础设施。项目报告说，会议有超过 443 名参会者，来自 50 个国家，合计 169 场活动，其中包括 50 多场演讲、39 场短讲、5 场讨论、59 场 BoF、10 个工作坊，以及用于集中开发和团队 sprint 的 DebCamp 周。[7] 文中还特别提到 dormant packages、包接纳挑战、Salsa-CI、每日新人引导、密钥签署、DPL 更新与内部团队会议。[7]
这份活动清单直接对应 Debian 的难题。休眠包影响发布质量。包接纳影响归档健康。Salsa-CI 影响变更可信度。新人引导影响维护者继承。密钥签署影响开发者信任。内部团队会议让受托小组在下一次冻结把每一次延迟放大之前，先校准政策、工具与人的容量。[7]
这也是题图有意义的原因。Debian 的发布契约不能化约为 britney、autopkgtests 与包元数据。这些工具需要有人知道何时移除一个包，何时 unblock 一个修复，何时指导维护者，何时升级技术争议，何时让一个发布继续等待。社会层与工程系统彼此嵌合，它本身就是工程系统的一部分。
采用 Debian 时，别读错它
Debian 最强的场景，是团队需要可预测的基础操作系统、宽阔的包归档、透明治理、长安全周期与保守升级行为。它适合服务器、设备、基础镜像、研究计算、公共基础设施、内部平台与衍生发行版，适合那些希望操作系统在生产中安静、在审计中可读的地方。[1][2][3][4]
它较弱的场景也清楚：团队需要快速移动的桌面栈、默认最新的上游语言运行时，或围绕单一硬件、单一云产品打磨过的厂商生命周期管理。Debian 仍可通过 backports、容器、厂商仓库或衍生系统服务这些环境，但这些层都是加在 Debian 契约之上，不能替代理解契约本身。
因此，采用问题应当说得更精确：基础 OS 要优化发布列车纪律、归档一致性与公开治理记录，还是要优化最快的上游摄入路径？Debian 在 2026 年的维护者信号，是它依然知道自己站在哪一边。它接受更慢的摄入速度，让归档可以成为一个稳定整体。
这就是 trixie 留下的教训。Debian 的发布机器超出一张日历。它是一份由基础文件、授权结构、迁移关口、冻结政策、架构支持、安全周期与贡献者工作共同构成的契约。结果避开时髦表达，却异常可检查。对基础操作系统来说，这仍然是严肃优势。
来源
- Debian 项目，《Debian Social Contract》1.2 版，涵盖社会契约、Debian 自由软件指导原则、
contrib、non-free与固件边界。 - Debian 项目，《Constitution for the Debian Project》1.9 版，涵盖决策机构、开发者权力、受托人、选举与技术委员会权限。
- Debian 项目，《Debian "trixie" Release Information》，涵盖 Debian 13.4、13.0 初始发布日期、支持期限、LTS 阶段与支持架构。
- Debian 项目，《Debian 13 "trixie" released》（2025 年 8 月 9 日），涵盖包数量、开发时长、架构变化、安装器说明与升级指引。
- Debian 发布团队，《trixie Freeze Timeline and Policy》，涵盖软冻结、硬冻结、完全冻结关口、迁移延迟、unblock 请求与可接受变更。
- Debian 发布团队，《A short introduction to migrations》，britney2 文档，涵盖政策检查、有效候选、回归、可安装性测试与迁移尝试。
- Debian 项目，《DebConf25 closes in Brest and DebConf26 announced》（2025 年 8 月 3 日），涵盖参会人数、国家、活动、DebCamp、sprint 与新人引导。
- Michael Larabel，Phoronix，《Debian 13.0 "Trixie" Now Available - Powered By Linux 6.12 LTS》（2025 年 8 月 9 日），关于内核、桌面、编译器、RISC-V、HTTP Boot、
time_t与可复现构建的独立发布读解。 - Wikimedia Commons，《File:Debconf15 group photo.jpg》，本文使用的 2015 年 DebConf 合影来源页，摄影者 Aigars Mahinovs。