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