Debian 是一个复杂的大型操作系统，也是一个庞大的开源项目。它已经有 30 年的历史了。对许多人来说，它的某些方面很奇怪。大多数这样的事情都是有原因的，但很难找到原因是什么。本文试图回答一些这样的问题，但并不详细介绍这个项目的历史。
Debian 想要成为什么
Debian 希望成为一个高质量、安全的通用操作系统，它只由自由和开放源码软件组成，可运行于世界上大多数正在使用的计算机上。
我所说的 “通用 ”是指 Debian 应适合大多数人的大多数用途。不管出于什么原因，总会有不适合的情况，但这是一个很好的目标。其他一些发行版的目标是特定用途：台式机、服务器、玩游戏、做科学研究等等。通用或特定目的都可以，但目标的选择会导致不同的决定。
对 Debian 而言，“通用 ”的目标意味着 Debian 不会根据软件的用途来选择软件包。Debian 在此做出的唯一真正的选择是软件是否免费，以及 Debian 是否有可能维护一个高质量的软件包。
章程、权力结构、管理
Debian 是比较明确的民主开源组织之一。它有明确的决策流程，每年选举一位项目负责人。此外，项目负责人的权力受到严格限制，大多数通常与领导权相关的权力都明确授权给其他人。
这一点的历史背景是，Debian 项目的第一任领导者在选择下台之前都是隐性的全能独裁者。后来，一位项目负责人太过分了，一场叛乱将他们赶下了台，从此引入了民主制度。作为其中的一部分，项目有了正式的章程，规定了项目的规则。
Debian 之所以有这样的规则，是因为较少的规则和较少的官僚主义在 Debian 早期的历史中并不奏效。
社会契约与 Debian 自由软件指南
20 世纪 90 年代中期，在开放源码一词出现之前，“自由软件 ”的定义是由自由软件基金会（Free Software Foundation）制定的，但其中有很多解释的余地。Debian 希望有更明确的规则，于是制定了《Debian 自由软件指南》，并将其作为社会契约的一部分。
社会契约是 Debian 对自己和整个世界关于 Debian 是什么和做什么的承诺。DFSG 就是其中的一部分。它是 Debian 的基础文件，Debian 章程故意使修改它变得困难。
更详细的规则使 Debian 可以接受的内容更加明确，并简化了相关讨论。当然，仍有许多问题需要讨论。
DFSG 后来成为开源定义的基础。
自成一体
Debian 坚持自成一体。任何由 Debian 打包的 Debian 软件都必须只使用 Debian 中的依赖项进行构建（编译）。此外，Debian 中的一切都必须由 Debian 构建。这会造成大量额外工作。例如，当前的编程语言工具通常假定它可以在构建时从在线资源库中下载依赖项，而这对于 Debian 来说是不可接受的。
其主要原因是，依赖项以后可能无法使用。Debian 无法控制第三方软件包库，如果某个软件包或整个软件包库消失，Debian 可能无法重建该软件包。Debian 需要重建软件包来升级到新的编译器、修复安全问题、移植到新的架构，或者只是对软件包进行一些修改，包括错误修复。
如果 Debian 不是自足的，那么当需要发布紧急安全修复时，它就会受到数以万计的软件包及其所有依赖软件的摆布。这对 Debian 来说是不可接受的，因此 Debian 选择将所有依赖包打包。
当然，这也意味着 Debian 打包工作会非常繁重。
无捆绑库
Debian 避免使用与软件包捆绑在一起的库副本或其他依赖项。许多上游项目发现捆绑或 “供应商 ”依赖关系更容易，但对 Debian 而言，这意味着某些流行库可能有许多副本。当需要修复此类库中的安全问题或其他严重问题时，Debian 必须找到所有拷贝来修复它们。这可能是一项繁重的工作，而且如果安全问题十分紧急，这样做会浪费宝贵的时间。
举个例子：zlib 被大量项目使用。就其本质而言，它需要处理的数据可能会被用来利用库中的漏洞。这种情况已经发生。有一次，Debian 在其归档文件中发现了数十个捆绑的 zlib 副本，并花费了大量精力确保 Debian 中的软件包只使用打包版本的 zlib。
因此，Debian 选择在软件打包时，在紧急之前先下手为强，确保 Debian 中的软件包使用 Debian 中打包的库版本。
这并不总能得到上游开发者的赞赏，他们更希望只需要处理他们打包的库版本。这也是他们验证自己软件的版本。这有时会导致与 Debian 的摩擦。
会员程序
鉴于 Debian 作为操作系统的规模和复杂性，以及它的受欢迎程度，项目需要信任它的成员。这尤其意味着要信任那些上传新软件包的人。由于 20 世纪 90 年代 Linux 的技术限制，每个 Debian 软件包在安装过程中都有完全的 root 访问权限。换句话说，每一个 Debian 开发者都有可能成为任何一台运行 Debian 的机器的 root 用户。运行 Debian 的机器数以千万计，这意味着潜在的巨大能量。
Debian 通过各种方式审查新成员。最理想的情况是，每一位新成员都已经在 Debian 开发社区中工作了足够长的时间，以至于被其他人所熟知，并在社区中建立了信任。
对于想要加入 Debian 的人来说，这个过程可能相当令人沮丧，尤其是对于习惯于小型开源项目的人来说。
发布代码名称
Debian 为每个主要版本指定一个代码名。这样做的初衷是为了降低镜像 Debian 软件包存档的成本。
20 世纪 90 年代中期，当 Debian 即将发布 1.0 版本时，并没有使用代码名。取而代之的是，存档中的每个版本都有一个以版本命名的目录。开发一个新版本需要一段时间，因此 “1.0 ”目录是提前创建的。不幸的是，一家光盘发行商在 Debian 完成 1.0 版本的制作之前，就过早地大量生产了一张标有 1.0 版本的光盘。这意味着，拿到 Debian 1.0 光盘的人得到的实际上并不是 1.0。
要避免这种情况再次发生，一个显而易见的办法是将发行版放在一个名为 “1.0-not-released ”的目录下，并在发行版完成后将该目录重命名为 “1.0”。然而，这意味着当目录名改变时，所有镜像都必须重新下载发布版本。鉴于 Debian 的庞大体积（数百个软件包！数十兆字节！），这样做的成本会很高。因此，Debian 选择使用代号来代替。
后来，“池 ”结构被添加到 Debian 档案中。有了这种结构，所有发行版的文件都在同一个目录树中，而元数据文件则指定了哪些文件属于每个发行版。这让镜像变得更容易。现在也许可以取消代码名，只使用版本名，但我不知道 Debian 是否会对此感兴趣。
变化缓慢
如上所述，Debian 非常庞大。它非常庞大。它是巨大的，它真的一点也不小了。
大船停得慢。大型项目变化缓慢。Debian 中任何会影响大部分软件包的变化都可能需要数百名志愿者来完成。这不会很快发生。
有时，只需少量人员就能完成工作，Debian 有相应的流程来实现这一点。举例来说，如果上传了新版本的 GNU C 编译器，那么找出其他软件包中需要修正的地方的工作通常只需要几个人就能完成。
通常情况下，修改需要时间，因为需要达成共识，而这就需要广泛的讨论，这需要时间，而且很少有人能在短时间内完成。
这也意味着 Debian 开发人员在技术决策上倾向于保守。他们通常倾向于不需要大规模改动的解决方案。
Debianlinux| 2025年05月23日
你也许会喜欢这些文章：
no no no. 不要使用kill -9
事实证明linux永远是number 1
送给Linux爱好者精彩有趣的高清Linux壁纸
动画演示10个有趣但毫无用处的Linux命令
12款最佳Linux命令行终端工具
chroot 技术–Linux 系统的瑞士军刀
Rust 和 C 文件系统 API
摆在猪前的鲜花
软件开发工具推荐 ：Gow
这些奇怪的unix/linux命令名称都是什么意思？
对于这篇文章，你的反应是：
0
俺的神呀 0
赞一个 0
飘过~ 0
强 0
标题党 0
很实用 0
好文 0
笑死了 0
mark 0
敬佩 0
垃圾 0
0
看样子你已经点过这个了！
抱歉，你最多只能点三个！