Debian 项目 关于开始 （GR，一般决议）项目开发商 ，这将决定该项目未来关于绑定到 systemd 的政策、对替代 init 系统的支持以及与不使用 systemd 的派生发行版的互操作性。 投票将持续至27月28日（含），结果将于XNUMX月XNUMX日公布。
让我们回顾一下2014年技术委员会 systemd 上的默认分发，但不是 关于支持多种供应系统的决定（表明委员会不愿意就此问题做出决定的项目赢得了投票）。 委员会领导建议软件包维护者继续支持 sysvinit 作为替代 init 系统，但表示他不能强加自己的观点，并且应根据每种情况独立做出决定。
此后，一些开发人员尝试 全体投票，但初步投票表明，无需就使用多个初始化系统的问题做出决定。 几个月前，之后 由于与 libsystemd 冲突，在测试分支中包含了 elogind 包（在没有 systemd 的情况下运行 GNOME 所必需的），Debian 项目负责人再次提出了这个问题，因为开发人员无法达成一致，他们的沟通变成了对抗并陷入了死胡同。
当前的投票将允许通过有关多个供应系统的政策，如果要求支持替代系统的条款获胜，维护人员将无法忽视或拖延此类问题。 经过对项目负责人最初提出的三个投票点进行讨论后，选项数量扩大到了八个。 投票时，您可以一次选择多个项目，并按偏好程度对所选项目进行排名。 参与维护软件包和维护基础设施的大约一千名开发者拥有投票权。
建议选项：
主要关注点是systemd。 提供对替代 init 系统的支持不是优先事项，但维护人员可以选择在包中包含此类系统的 init 脚本。
支持各种 init 系统，并能够使用 systemd 以外的 init 系统启动 Debian。
要运行服务，包必须包含 init 脚本；仅提供 systemd 单元文件而不提供 sysv init 脚本是不可接受的。
systemd 仍然是首选，但保留了维护替代初始化系统的可能性。 诸如 elogind 之类的技术被认为非常重要，这些技术允许绑定到 systemd 的应用程序在替代环境中运行。 软件包可能包含替代系统的初始化文件。
支持不使用 systemd 的系统，但不进行会阻碍开发的更改。 开发人员同意在可预见的未来支持多个 init 系统，但也认为有必要努力改进 systemd 支持。 具体解决方案的开发和维护应该留给对这些解决方案感兴趣的社区，但其他维护者应该在需要时积极帮助和贡献问题解决。 理想情况下，包应该使用任何 init 系统来运行，这可以通过提供传统的 init 脚本或使用允许它们在没有 systemd 的情况下工作的其他机制来实现。 没有 systemd 就无法工作被认为是一个 bug，但不是一个发布阻塞的 bug，除非有一个现成的解决方案可以在没有 systemd 的情况下工作，但他们拒绝保存它（例如，当问题是由于删除一个之前提供的初始化脚本）。
支持可移植性，而不引入阻碍开发的更改。 Debian 继续被视为集成提供相同或相似功能的不同软件的桥梁。 硬件平台和软件堆栈之间的可移植性是一个重要目标，并且鼓励替代技术的集成，即使其创建者的世界观与普遍共识不同。 关于systemd和其他初始化系统的位置与第4点完全一致。
强制支持多个初始化系统。 提供使用 systemd 以外的 init 系统运行 Debian 的能力对于该项目仍然很重要。 每个软件包必须与 systemd 以外的 pid1 处理程序配合使用，除非该软件包中包含的软件最初打算仅与 systemd 配合使用，并且不支持在没有 systemd 的情况下运行（缺少初始化脚本不算作仅与 systemd 配合使用的情况） 。
支持可移植性和多种实现。 总体原则与第 5 点完全相同，但对 systemd 和 init 系统没有具体要求，也不对开发人员强加任何义务。 鼓励开发者考虑彼此利益，做出妥协，找到各方都满意的共同解决方案。
继续讨论。 该项目可用于降级不可接受的选项。
来源： opennet.ru
