Sam Hartman，Debian 项目负责人， 了解与作为分发的一部分交付 elogind 包相关的分歧。 XNUMX月，负责准备发布的团队 将 elogind 包含在测试分支中，因为该软件包与 libsystemd 冲突。
回想一下， 提供运行 GNOME 所需的接口，无需安装 systemd。 该项目是作为 systemd-logind 的一个分支而建立的，放置在一个单独的包中，并且摆脱了与 systemd 组件的绑定。 除此之外，elogind 还提供了自己版本的 libelogind 库，该库采用了 libsystemd 中提供的许多功能，并在安装过程中替换了该库。
阻塞的原因是与 systemd 包冲突以及用替代 libelogind 替换 libsystemd 的危险，后者在 ABI 级别与源库完全不兼容。
该软件包将 elogind 标记为与 systemd 库冲突，但它本质上被设计为仅在没有 systemd 的情况下工作，并且与 systemd 冲突实际上是有益的，因为它可以防止错误安装 elogind。 另一方面，在当前形式下，尝试通过 APT 将配置从 systemd 更新到使用 sysvinit 和 elogind 的版本会导致 APT 不工作。 但即使消除了这个缺点，如果不删除已安装的用户环境，从 systemd 到 elogind 的过渡仍然是不可能的。
elogind 开发人员是 调整 elogind 以在标准 libpam-systemd 之上工作，而不使用其自己的 libpam-elogind 层。 由于缺乏对切片概念的支持，elogind 向 libpam-systemd 的过渡受到阻碍，但 elogind 的开发人员并不希望实现完全兼容 API 并完全重复 systemd 的所有功能，因为 elogind 只提供了最少的功能。组织用户登录的功能，并不旨在复制所有 systemd 子系统。
上述技术问题的解决本应在发布团队与 elogind 和 systemd 维护者的交互层面上解决，但由于团队无法达成一致，项目负责人被迫介入，共同工作发展为对抗，解决方案问题陷入了僵局，双方各有各的道理。 根据 Sam Hartman 的说法，情况正接近需要进行全民投票（GR，一般决议）的状态，社区将决定 init 的替代系统以及对 sysvinit 和 elogind 的支持。
如果项目成员投票支持 init 系统多样化，所有维护人员将共同努力解决这个问题，或者指定特定的开发人员来解决这个问题，维护人员将无法再忽视替代的 init 系统、保持沉默或延迟进程。
目前已经在存储库中 1033 个软件包为 systemd 提供服务单元，但不包含 init.d 脚本。 为了解决这个问题 默认情况下提供服务文件，但准备一个处理程序，该处理程序将自动解析这些文件中的命令并根据它们生成 init.d 脚本。
如果社区认为 Debian 对单个 init 系统有足够的支持，我们就可以不再担心 sysvinit 和 elogind，而只关注单元文件和 systemd。 此决定将对不使用 Linux 内核的端口产生负面影响（, и ），但主档案中还没有这样的端口，并且它们没有状态 .
绑定到 systemd 也会使将来改变分发方向变得更加困难，并将限制在初始化和服务管理领域的进一步实验。 维护 elogind 处于工作状态比删除它然后尝试再次添加要容易得多。 每个决策选项都有优点和缺点，因此在投票之前需要对所有优点和缺点进行充分讨论。
来源： opennet.ru