Debian init系统投票结果已总结

发表 发现 一般投票 (GR,通用决议) Debian 项目开发人员在参与软件包维护和基础设施维护时,就支持多个 init 系统的问题进行了研究。 列表中的第二项(“B”)获胜 - systemd 仍然是首选,但维护替代初始化系统的可能性仍然存在。 投票采用以下方法进行 孔多塞,其中每个选民按偏好顺序对所有选项进行排名,并且在计算结果时,会考虑有多少选民更喜欢一种选项而不是另一种选项。

获胜的提案承认 systemd 服务单元是配置守护进程和服务运行的首选方式,但也承认在某些环境中开发人员和用户可以创建和使用替代 init 系统以及 systemd 功能的替代功能。 替代解决方案的开发人员需要资源来开展工作并格式化其包。 用于运行绑定到特定于 systemd 的接口的应用程序的替代解决方案(例如 elogind)对于该项目仍然很重要。 支持此类举措需要在开发替代技术与项目其他部分交叉的领域提供援助,例如推迟补丁审查和讨论。

包可以包含 systemd 单元文件和用于启动服务的 init 脚本。 软件包可以使用软件包维护者希望的任何 systemd 功能,只要这些功能符合 Debian 规则并且不与其他软件包中的实验性或不受支持的 Debian 功能相关联。 除了 systemd 之外,软件包还可能包括对替代 init 系统的支持,并提供组件来替换特定于 systemd 的接口。 关于包含补丁的决定由维护者作为标准程序的一部分做出。 Debian 致力于与选择了其他 init 系统的衍生发行版合作,但交互是在维护者级别上构建的,维护者级别决定第三方发行版准备的哪些功能被接受到主 Debian 发行版中以及哪些保留在维护者级别上。导数分布。

让我们回顾一下2014年技术委员会 批准 过渡 systemd 上的默认分发,但不是 解决了 关于支持多种供应系统的决定(表明委员会不愿意就此问题做出决定的项目赢得了投票)。 委员会领导建议软件包维护者继续支持 sysvinit 作为替代 init 系统,但表示他不能强加自己的观点,并且应根据每种情况独立做出决定。

此后,一些开发人员尝试 尝试进行 全体投票,但初步投票表明,无需就使用多个初始化系统的问题做出决定。 几个月前,之后 问题 由于与 libsystemd 冲突,在测试分支中包含了 elogind 包(在没有 systemd 的情况下运行 GNOME 所必需的),Debian 项目负责人再次提出了这个问题,因为开发人员无法达成一致,他们的沟通变成了对抗并陷入了死胡同。

考虑的选项:

  • 主要关注点是systemd。 提供对替代 init 系统的支持不是优先事项,但维护人员可以选择在包中包含此类系统的 init 脚本。
  • systemd 仍然是首选,但保留了维护替代初始化系统的可能性。 诸如 elogind 之类的技术被认为非常重要,这些技术允许绑定到 systemd 的应用程序在替代环境中运行。 软件包可能包含替代系统的初始化文件。
  • 支持各种 init 系统,并能够使用 systemd 以外的 init 系统启动 Debian。
    要运行服务,包必须包含 init 脚本;仅提供 systemd 单元文件而不提供 sysv init 脚本是不可接受的。

  • 支持不使用 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

    添加评论