Debian社区运作记录(202x)
2019-03-15 08:31:16 
阿炯
本文专用于记录Debian社区运作的大事记，截止2030前。
Debian 包维护者 Michael Stapelberg 因对 Debian 社区的现状不满而宣布退出 Debian 的维护，该消息引发了人们对于 Debian 的担忧。3月11 日，邮件列表上一封标题为“Leaderless Debian”的公开信进一步加深了这种担忧。
Debian 社区目前正在进行领导人选举，3月3-10日是候选人提名阶段；然而，截至公开信发出的 11 日，还没有一位符合资格的 Debian 开发者提交申请。此前的 Debian 领导人 Chris Lamb 一直被寄予厚望，他已经连任了两年，但是今年他公开表示因为一些 Debian 相关的与私人的原因不参与竞选。所以，现在出现了尴尬的情况：“提名期已经结束，竞选期已经开始，但没有人在做任何竞选活动。”
为什么大家都不愿担任领导人呢？
Debian 领导人的主要职能有两项：一方面是代表 Debian 到世界各地，在会议上进行分享，同时处理项目与其它团队和公司的关系；另一方面是行政上的，领导人要管理项目资金，任命开发者在项目中担任不同角色，并负责项目中的一些细节。
但是公开信中也指出，实际上，因为 Debian 项目把各种各样的权限都下放到社区成员中，导致领导人的实权实际上并没有多少。比如，个别开发者几乎可以完全控制他们维护的软件包；开发人员之间的技术分歧很大的时候，将由项目技术委员会处理；发布管理者与 FTP 主人有权最终决定项目实际发布的内容，以及何时发布；项目秘书负责确保遵循必要的程序；政策团队处理项目的大部分总体设计。
另一方面，Debian 领导人这个职位需要花费大量时间与精力，但它是没有薪水回报的。公开信表示，如果之后确认这正是问题所在，那么社区可能会考虑做出一些改变，创造一个有偿的职位来承担领导人的工作。目前没有一位开发者提名，根据 Debian 的章程，提名期延长了一周，也就是 3 月 17 日截止。如果在这个时间之前还没有人提名，那么提名期还会再延长一周。该流程将无限持续下去，“直到有人屈服并提交他们的名字”。
而除了无人提名的尴尬，更严重的问题是，根据章程，只要任期结束，当前的 Debian 领导人 Chris Lamb 就可以不再履行职责，如果在那个时候还没有选出新的领导人（毕竟提名期是可以无限延长的），那么社区就会处在群龙无首的状态，Debian 将会陷入困境，项目运作的各方面都会停滞不前。
然而，好消息是Debian章程也预想了这种情况，在没有项目负责人的情况下，技术委员会主席和项目秘书有权做出各种决定，前提是他们能够达成一致。信中对这种情况表示乐观：“由于 Debian 开发人员向来以‘非争论群体’著称，所以达成一致应该不成问题。”但很明显这种不确定因素过高的方案不是一个良策。
联系一下此前 Debian 包维护者 Michael 对社区的不满，他认为 Debian 整个开发评估流程都非常迟缓，比如补丁的评估没有截止日期，有时候他会收到通知说几年前递交的补丁现在合并了；赋予维护者的个人自由度太高，一些维护者可以出于个人喜好拒绝合作等，这些都对 Debian 的发展产生不好的影响。就像 Michael，许多人都认为社区内部给予开发者的自由度过高，并且带来不好的影响。按照前边对于 Debian 领导人实权的介绍，这似乎可以理解为现在迟迟没有人愿意竞选领导人的主要原因。再加上开发流程迟缓等问题，如果今年的领导人选举直到 Chris 卸任都没有结果出现，那么 Debian 更是岌岌可危。
信奉“Debian 好”的开发者们，拯救组织的机会就摆在眼前，快去参与竞选吧。
Sam Hartman 当选 Debian 社区领导人
接上 Debian 正愁于新任领导人选举的事，现在最新消息是选举投票结果已经出炉，Sam Hartman 当选了 Debian 项目新任领导人。
Sam Hartman 于 2000 年加入 Debian 社区，他曾担任 MIT Kerberos Consortium 的首席技术专家，在竞选 Debian 领导人时其主张让 Debian 保持有趣，Keeping Debian Fun，他提出几点可以实现这一目标的想法，比如简化流程与交互，更加容易去倾听为 Debian 做出贡献的开发者的想法；推动社区内一些经常被抱怨却没有解决的问题的讨论，并最终做出长效的决策。Sam 认为只有当漫长而激烈的讨论消失时，当项目得以推进时，当流程或工具不再繁杂时，当项目安全时，Debian 对于开发者来说才是有趣的。
Debian 似乎多被吐槽开发流程缓慢、赋予维护者的个人自由度太高等问题，还记得上个月核心包维护者愤而发文宣布退出对项目的维护。另一边，Debian 项目把各种各样的权限都下放到社区成员中，导致领导人的实权实际上并没有多少。比如，个别开发者几乎可以完全控制他们维护的软件包；开发人员之间的技术分歧很大的时候，将由项目技术委员会处理；发布管理者与 FTP 主人有权最终决定项目实际发布的内容，以及何时发布；项目秘书负责确保遵循必要的程序；政策团队处理项目的大部分总体设计，而这也正是之前迟迟没有人参与领导人竞选的主要原因之一。
Sam 带着“Keeping Debian Fun”的想法而来，希望他能为社区带来一些改变吧。
具体投票情况查看这里。
Jonathan Carter 再次当选为 Debian 项目负责人
2021 Debian 项目负责人 (DPL, Debian Project Leader) 的选举结果已于4月中旬公布，Jonathan Carter 再次当选为新一任的 DPL，他的新任期将从2021-04-21开始。被提名参与本届选举的人员总共两名，分别是 Jonathan Carter 和前两届 DPL Sruthi Chandran。
Jonathan Carter
Sruthi Chandran
据介绍，DPL 选举投票是不记名投票，参与的投票人数为 1018，其中支持 Jonathan Carter 的有 421 票，高于 Sruthi Chandran 的 341 票。具体投票过程与结果分析访问此处。
Jonathan Carter 在竞选宣言中描述了他的工作目标：
改进财务相关工作，例如提升财务透明度，更好地追踪资金的收入和使用情况
实行支出政策 (expendature policy)，主要是让项目成员更清楚他们可以在哪些方面花钱以及如何花钱，Jonathan Carter 表示项目成员之间对于这方面没有达成一致的认识，通常会导致这些成员不使用本来可以让 Debian 项目受益的资金
考虑正式注册 Debian 组织
今年选举 DPL 的投票中还提及到了是否应就 Richard Stallman 重新加入 FSF 董事会发表声明的投票。最终的结果是 Debian 决定选择对此事不发声明。获最对赞成票的提案是：“Debian 项目不会就 Richard Stallman 是否应该被从领导岗位上撤下来发表公开声明。任何希望就此问题（共同）签署任何一封公开信的个人（包括 Debian成员），请以个人身份签署。"
连任三届，Jonathan Carter 当选为 Debian 项目负责人
2022年Debian 项目负责人 (DPL, Debian Project Leader) 的选举结果已公布，Jonathan Carter 再次当选为新一任的 DPL，他的新任期将从 2022 年 4 月 21 日开始。被提名参加本届选举的候选者有三人：
Felix Lechner [lechner@debian.org] [nomination mail] [platform]
Jonathan Carter [jcc@debian.org] [nomination mail] [platform]
Hideki Yamane [henrich@debian.org] [nomination mail] [platform]
据介绍，本届 DPL 选举投票采用了孔多塞投票法 (Condorcet voting)，简单介绍如下：投票者将候选人或候选的项目随自己的喜好而排名，例如第一意愿写“1”，第二意愿写“2”，如此类推。这种方法将每个选项与所有其他的选项成对比较，一次一个，而击败所有其他选项的选项便是赢家。只要一个选项在大多数选票上的位置高于另一个选项，那么它便击败了那个选项。例如在三名候选人中，一个候选人可能具有最少的第一选择，但与其他两个候选人赢得了面对面的选举。具体投票过程与结果分析访问这里。
Jonathan Carter 在竞选宣言中描述了他的工作目标：
考虑正式注册 Debian 组织，包括成立基金会等工作（这也是 2021 年竞选的议程）
改进会计工作、梳理 Debian 资产（这也是 2021 年竞选的议程）
进军固件领域，接触 FSF、OSI 和 LF，看看在固件问题上有没有合作的方式。此外，如果可能的话，提供一些资金用于开发开源固件
以及说明继续参与竞选的原因——实现在上届任期内未完成的目标。
Debian 放弃 32 位 MIPS Little Endian “mipsel” 端口
Debian 开发人员于2023提9月上旬在邮件列表中宣布将 mipsel 端口从 Debian unstable/experimental 中删除的消息。
mipsel 曾是 Debian 中最古老的架构之一，仅次于 i386 和 amd64。Debian 12 "Bookworm" 将是最后一个支持 MIPS 小端 (little-endian) 架构的版本。放弃 MIPS 小端架构的原因包括：2038 年的 “Y2038” 问题尚未解决、2G 用户空间内存限制、以及 Debian 开发人员缺乏维护该架构的人力。因此，mipsel 将从 Debian 官方发布的架构中删除，而 MIPS64EL 作为 64-bit little-endian 变体将继续保留。
科技媒体 Phoronix 认为，那些仍在运行 32 位 MIPS little-endian 的用户，很可能都是运行在路由器等老式嵌入式设备上，因此也不可能频繁更新到较新的 Debian 版本。鉴于此，在最近的 Debian 12 发布之后，考虑到开发人员资源的匮乏和其他提到的技术限制，将其从 experimental/testing 中删除是合理的。
停止支持 i386 架构
Debian GNU/Linux 团队在2023年12月的 DebConf 会议上决定，其 Linux 内核、Debian 安装器和 Debian 镜像团队未来将不再支持 i386 架构。这意味着用户需要考虑将系统迁移到更现代的架构，以确保系统的长期支持和兼容性。
i386 架构是英特尔的 32 位微处理器，最初被称为 80386，后来更名为 i386。它是 x86 架构的一部分，是早期个人电脑和工作站的中央处理单元（CPU）。i386 架构具有 32 位数据宽度和 32 位地址宽度，支持实模式、保护模式和虚拟模式。虽然 i386 架构已经过时，但它对后来的 x86 处理器设计产生了深远影响。i386 的后继产品包括 i486 和 P5 Pentium 系列处理器，这些处理器都是基于 i386 设计的后代产品。
此后用户可以通过两种方式来运行 i386：作为 amd64 系统上的多架构选项、作为其他架构系统上的 i386 chroot。
Debian 并不打算像 Ubuntu 那样将 i386 作为部分架构，arch:any 仍将包含 i386，因此一切都将默认构建。希望放弃 i386 支持的维护者可以在与软件包的反向（构建）依赖关系协调后放弃 i386 支持，就像放弃对其他架构的支持一样。Debian 方面指出，并不反对在出现这些变更时对基线进行修改。
考虑到其他 Linux 发行版多年来一直在放弃 i386，一些 Linux 发行版甚至提高了它们的 x86-64 微架构基线，看到 Debian 也最终也决定停止支持 i386，尤其是在 Debian 13 大约两年后发布之前，这并不太令人惊讶。
Debian Policy 4.7 发布
新版 Debian Policy Manual 已经于2024年4月上旬发布，概述了 Debian 围绕软件包归档和平台的各种设计问题的政策要求。v4.7 承认最近在 Debian 中引入的 non-free-firmware archive，允许在源代码软件包中使用 hard links，并且启动/停止服务的软件包大多包含 systemd units，除非它们明确用于其他启动系统。变更日志包括：
2.2.1
记录 *main* 归档区域中的源包可以在 *contrib* 归档区域中构建二进制包，尽管不鼓励这样做，除非源码包不便拆分。这并没有放宽 *main* 中的源包不得具有 *main* 之外的构建依赖项的要求。
2.2.2
添加了 “non-free-firmware” 归档区域。
3.9
维护脚本应尽可能使用 native overriding 机制而不是 dpkg-divert。维护脚本不得转移 systemd 组件使用的配置文件。
维护者脚本不得使用 systemd 配置文件的替代系统。
4.8
允许在源码包中存在 Hard links。
4.9
对于 contrib 中的软件包以及带有 “Autobuild: yes” 的非自由软件包，不再允许 d/rules 中 required targets 尝试网络访问。以前，只有 main 中的包有此限制。
5.6.13
如果没有上传二进制包，则 “.changes” 文件中不存在 “Description” 字段。
5.6.19
如果没有上传二进制包，则 “.changes” 文件中不存在 “Binary” 字段。
6.3
自动启动或停止系统服务的软件包必须包含 “systemd” 单元，除非该服务仅用于运行其他 init 系统的系统。以前，“systemd” 也支持 init 脚本，但该支持正在被删除。
该政策变更现已在 Debian Sid 开发中生效。
Debian 包维护者 Michael Stapelberg 因对 Debian 社区的现状不满而宣布退出 Debian 的维护，该消息引发了人们对于 Debian 的担忧。3月11 日，邮件列表上一封标题为“Leaderless Debian”的公开信进一步加深了这种担忧。
Debian 社区目前正在进行领导人选举，3月3-10日是候选人提名阶段；然而，截至公开信发出的 11 日，还没有一位符合资格的 Debian 开发者提交申请。此前的 Debian 领导人 Chris Lamb 一直被寄予厚望，他已经连任了两年，但是今年他公开表示因为一些 Debian 相关的与私人的原因不参与竞选。所以，现在出现了尴尬的情况：“提名期已经结束，竞选期已经开始，但没有人在做任何竞选活动。”
为什么大家都不愿担任领导人呢？
Debian 领导人的主要职能有两项：一方面是代表 Debian 到世界各地，在会议上进行分享，同时处理项目与其它团队和公司的关系；另一方面是行政上的，领导人要管理项目资金，任命开发者在项目中担任不同角色，并负责项目中的一些细节。
但是公开信中也指出，实际上，因为 Debian 项目把各种各样的权限都下放到社区成员中，导致领导人的实权实际上并没有多少。比如，个别开发者几乎可以完全控制他们维护的软件包；开发人员之间的技术分歧很大的时候，将由项目技术委员会处理；发布管理者与 FTP 主人有权最终决定项目实际发布的内容，以及何时发布；项目秘书负责确保遵循必要的程序；政策团队处理项目的大部分总体设计。
另一方面，Debian 领导人这个职位需要花费大量时间与精力，但它是没有薪水回报的。公开信表示，如果之后确认这正是问题所在，那么社区可能会考虑做出一些改变，创造一个有偿的职位来承担领导人的工作。目前没有一位开发者提名，根据 Debian 的章程，提名期延长了一周，也就是 3 月 17 日截止。如果在这个时间之前还没有人提名，那么提名期还会再延长一周。该流程将无限持续下去，“直到有人屈服并提交他们的名字”。
而除了无人提名的尴尬，更严重的问题是，根据章程，只要任期结束，当前的 Debian 领导人 Chris Lamb 就可以不再履行职责，如果在那个时候还没有选出新的领导人（毕竟提名期是可以无限延长的），那么社区就会处在群龙无首的状态，Debian 将会陷入困境，项目运作的各方面都会停滞不前。
然而，好消息是Debian章程也预想了这种情况，在没有项目负责人的情况下，技术委员会主席和项目秘书有权做出各种决定，前提是他们能够达成一致。信中对这种情况表示乐观：“由于 Debian 开发人员向来以‘非争论群体’著称，所以达成一致应该不成问题。”但很明显这种不确定因素过高的方案不是一个良策。
联系一下此前 Debian 包维护者 Michael 对社区的不满，他认为 Debian 整个开发评估流程都非常迟缓，比如补丁的评估没有截止日期，有时候他会收到通知说几年前递交的补丁现在合并了；赋予维护者的个人自由度太高，一些维护者可以出于个人喜好拒绝合作等，这些都对 Debian 的发展产生不好的影响。就像 Michael，许多人都认为社区内部给予开发者的自由度过高，并且带来不好的影响。按照前边对于 Debian 领导人实权的介绍，这似乎可以理解为现在迟迟没有人愿意竞选领导人的主要原因。再加上开发流程迟缓等问题，如果今年的领导人选举直到 Chris 卸任都没有结果出现，那么 Debian 更是岌岌可危。
信奉“Debian 好”的开发者们，拯救组织的机会就摆在眼前，快去参与竞选吧。
Sam Hartman 当选 Debian 社区领导人
接上 Debian 正愁于新任领导人选举的事，现在最新消息是选举投票结果已经出炉，Sam Hartman 当选了 Debian 项目新任领导人。
Sam Hartman 于 2000 年加入 Debian 社区，他曾担任 MIT Kerberos Consortium 的首席技术专家，在竞选 Debian 领导人时其主张让 Debian 保持有趣，Keeping Debian Fun，他提出几点可以实现这一目标的想法，比如简化流程与交互，更加容易去倾听为 Debian 做出贡献的开发者的想法；推动社区内一些经常被抱怨却没有解决的问题的讨论，并最终做出长效的决策。Sam 认为只有当漫长而激烈的讨论消失时，当项目得以推进时，当流程或工具不再繁杂时，当项目安全时，Debian 对于开发者来说才是有趣的。
Debian 似乎多被吐槽开发流程缓慢、赋予维护者的个人自由度太高等问题，还记得上个月核心包维护者愤而发文宣布退出对项目的维护。另一边，Debian 项目把各种各样的权限都下放到社区成员中，导致领导人的实权实际上并没有多少。比如，个别开发者几乎可以完全控制他们维护的软件包；开发人员之间的技术分歧很大的时候，将由项目技术委员会处理；发布管理者与 FTP 主人有权最终决定项目实际发布的内容，以及何时发布；项目秘书负责确保遵循必要的程序；政策团队处理项目的大部分总体设计，而这也正是之前迟迟没有人参与领导人竞选的主要原因之一。
Sam 带着“Keeping Debian Fun”的想法而来，希望他能为社区带来一些改变吧。
具体投票情况查看这里。
Jonathan Carter 再次当选为 Debian 项目负责人
2021 Debian 项目负责人 (DPL, Debian Project Leader) 的选举结果已于4月中旬公布，Jonathan Carter 再次当选为新一任的 DPL，他的新任期将从2021-04-21开始。被提名参与本届选举的人员总共两名，分别是 Jonathan Carter 和前两届 DPL Sruthi Chandran。
Jonathan Carter
Sruthi Chandran
据介绍，DPL 选举投票是不记名投票，参与的投票人数为 1018，其中支持 Jonathan Carter 的有 421 票，高于 Sruthi Chandran 的 341 票。具体投票过程与结果分析访问此处。
Jonathan Carter 在竞选宣言中描述了他的工作目标：
改进财务相关工作，例如提升财务透明度，更好地追踪资金的收入和使用情况
实行支出政策 (expendature policy)，主要是让项目成员更清楚他们可以在哪些方面花钱以及如何花钱，Jonathan Carter 表示项目成员之间对于这方面没有达成一致的认识，通常会导致这些成员不使用本来可以让 Debian 项目受益的资金
考虑正式注册 Debian 组织
今年选举 DPL 的投票中还提及到了是否应就 Richard Stallman 重新加入 FSF 董事会发表声明的投票。最终的结果是 Debian 决定选择对此事不发声明。获最对赞成票的提案是：“Debian 项目不会就 Richard Stallman 是否应该被从领导岗位上撤下来发表公开声明。任何希望就此问题（共同）签署任何一封公开信的个人（包括 Debian成员），请以个人身份签署。"
连任三届，Jonathan Carter 当选为 Debian 项目负责人
2022年Debian 项目负责人 (DPL, Debian Project Leader) 的选举结果已公布，Jonathan Carter 再次当选为新一任的 DPL，他的新任期将从 2022 年 4 月 21 日开始。被提名参加本届选举的候选者有三人：
Felix Lechner [lechner@debian.org] [nomination mail] [platform]
Jonathan Carter [jcc@debian.org] [nomination mail] [platform]
Hideki Yamane [henrich@debian.org] [nomination mail] [platform]
据介绍，本届 DPL 选举投票采用了孔多塞投票法 (Condorcet voting)，简单介绍如下：投票者将候选人或候选的项目随自己的喜好而排名，例如第一意愿写“1”，第二意愿写“2”，如此类推。这种方法将每个选项与所有其他的选项成对比较，一次一个，而击败所有其他选项的选项便是赢家。只要一个选项在大多数选票上的位置高于另一个选项，那么它便击败了那个选项。例如在三名候选人中，一个候选人可能具有最少的第一选择，但与其他两个候选人赢得了面对面的选举。具体投票过程与结果分析访问这里。
Jonathan Carter 在竞选宣言中描述了他的工作目标：
考虑正式注册 Debian 组织，包括成立基金会等工作（这也是 2021 年竞选的议程）
改进会计工作、梳理 Debian 资产（这也是 2021 年竞选的议程）
进军固件领域，接触 FSF、OSI 和 LF，看看在固件问题上有没有合作的方式。此外，如果可能的话，提供一些资金用于开发开源固件
以及说明继续参与竞选的原因——实现在上届任期内未完成的目标。
Debian 放弃 32 位 MIPS Little Endian “mipsel” 端口
Debian 开发人员于2023提9月上旬在邮件列表中宣布将 mipsel 端口从 Debian unstable/experimental 中删除的消息。
mipsel 曾是 Debian 中最古老的架构之一，仅次于 i386 和 amd64。Debian 12 "Bookworm" 将是最后一个支持 MIPS 小端 (little-endian) 架构的版本。放弃 MIPS 小端架构的原因包括：2038 年的 “Y2038” 问题尚未解决、2G 用户空间内存限制、以及 Debian 开发人员缺乏维护该架构的人力。因此，mipsel 将从 Debian 官方发布的架构中删除，而 MIPS64EL 作为 64-bit little-endian 变体将继续保留。
科技媒体 Phoronix 认为，那些仍在运行 32 位 MIPS little-endian 的用户，很可能都是运行在路由器等老式嵌入式设备上，因此也不可能频繁更新到较新的 Debian 版本。鉴于此，在最近的 Debian 12 发布之后，考虑到开发人员资源的匮乏和其他提到的技术限制，将其从 experimental/testing 中删除是合理的。
停止支持 i386 架构
Debian GNU/Linux 团队在2023年12月的 DebConf 会议上决定，其 Linux 内核、Debian 安装器和 Debian 镜像团队未来将不再支持 i386 架构。这意味着用户需要考虑将系统迁移到更现代的架构，以确保系统的长期支持和兼容性。
i386 架构是英特尔的 32 位微处理器，最初被称为 80386，后来更名为 i386。它是 x86 架构的一部分，是早期个人电脑和工作站的中央处理单元（CPU）。i386 架构具有 32 位数据宽度和 32 位地址宽度，支持实模式、保护模式和虚拟模式。虽然 i386 架构已经过时，但它对后来的 x86 处理器设计产生了深远影响。i386 的后继产品包括 i486 和 P5 Pentium 系列处理器，这些处理器都是基于 i386 设计的后代产品。
此后用户可以通过两种方式来运行 i386：作为 amd64 系统上的多架构选项、作为其他架构系统上的 i386 chroot。
Debian 并不打算像 Ubuntu 那样将 i386 作为部分架构，arch:any 仍将包含 i386，因此一切都将默认构建。希望放弃 i386 支持的维护者可以在与软件包的反向（构建）依赖关系协调后放弃 i386 支持，就像放弃对其他架构的支持一样。Debian 方面指出，并不反对在出现这些变更时对基线进行修改。
考虑到其他 Linux 发行版多年来一直在放弃 i386，一些 Linux 发行版甚至提高了它们的 x86-64 微架构基线，看到 Debian 也最终也决定停止支持 i386，尤其是在 Debian 13 大约两年后发布之前，这并不太令人惊讶。
Debian Policy 4.7 发布
新版 Debian Policy Manual 已经于2024年4月上旬发布，概述了 Debian 围绕软件包归档和平台的各种设计问题的政策要求。v4.7 承认最近在 Debian 中引入的 non-free-firmware archive，允许在源代码软件包中使用 hard links，并且启动/停止服务的软件包大多包含 systemd units，除非它们明确用于其他启动系统。变更日志包括：
2.2.1
记录 *main* 归档区域中的源包可以在 *contrib* 归档区域中构建二进制包，尽管不鼓励这样做，除非源码包不便拆分。这并没有放宽 *main* 中的源包不得具有 *main* 之外的构建依赖项的要求。
2.2.2
添加了 “non-free-firmware” 归档区域。
3.9
维护脚本应尽可能使用 native overriding 机制而不是 dpkg-divert。维护脚本不得转移 systemd 组件使用的配置文件。
维护者脚本不得使用 systemd 配置文件的替代系统。
4.8
允许在源码包中存在 Hard links。
4.9
对于 contrib 中的软件包以及带有 “Autobuild: yes” 的非自由软件包，不再允许 d/rules 中 required targets 尝试网络访问。以前，只有 main 中的包有此限制。
5.6.13
如果没有上传二进制包，则 “.changes” 文件中不存在 “Description” 字段。
5.6.19
如果没有上传二进制包，则 “.changes” 文件中不存在 “Binary” 字段。
6.3
自动启动或停止系统服务的软件包必须包含 “systemd” 单元，除非该服务仅用于运行其他 init 系统的系统。以前，“systemd” 也支持 init 脚本，但该支持正在被删除。
该政策变更现已在 Debian Sid 开发中生效。
该文章最后由 于 2024-04-09 10:38:49 更新，目前是第 2 版。