Сем Хартман (Sam Hartman), лідер проекту Debian, розібратися в розбіжностях, пов'язаних з постачанням пакету elogind у складі дистрибутива. У липні команда, яка відповідає за підготовку релізів, включення elogind у гілку testing, тому що даний пакет конфліктує з libsystemd.
Нагадаємо, що надає інтерфейси, необхідні для роботи GNOME без встановлення systemd. Проект заснований як відгалуження від systemd-logind, винесене в окремий пакет і позбавлене прив'язки до компонентів systemd. У тому числі elogind надає свій варіант бібліотеки libelogind, яка бере на себе ряд функцій, що пропонуються в libsystemd, і замінює при встановленні цю бібліотеку.
В якості причин блокування був відзначений конфлікт з пакетом systemd і небезпека заміни libsystemd альтернативним варіантом libelogind, повністю не сумісним з вихідною бібліотекою на рівні 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 лише надає мінімальну функціональність для організації входу користувачів і не ставить за мету повторення всіх підсистем system.
Вирішення описаних технічних проблем має вирішуватися на рівні взаємодії команди випускає релізи і мейнтейнерів elogind і systemd, але лідер проекту був змушений втрутитися, оскільки команди не змогли домовитися, спільна робота переросла в протистояння і вирішення проблеми зайшло в глухий кут, в якому кожна сторона права по своєму . На думку Сема Хартмана, ситуація наближається до стану, що вимагає проведення загального голосування (GR, general resolution), в якому спільнота ухвалить рішення щодо альтернативних систем ініціалізації та підтримки sysvinit з elogind.
Якщо учасники проекту проголосують за диверсифікацію систем ініціалізації, усі мейнтейнери будуть залучені до спільної роботи з вирішення цього завдання або будуть призначені спеціальні відповідальні розробники для роботи над цією проблемою і ті, хто супроводжує, більше не зможуть ігнорувати альтернативну систему ініціалізації, відмовчуватися чи затягувати процес.
Нині у репозиторії вже 1033 пакети, що постачають сервісні юніти для systemd, але не включають скрипти init.d. Для вирішення цієї проблеми постачати за замовчуванням service-файли, але підготувати обробник, який автоматично розбирав команди з цих файлів і генерував на їх основі скрипти init.d.
Якщо спільнота вирішить, що в Debian достатньо підтримки однієї системи ініціалізації, можна більше не дбати про sysvinit і elogind, зосередившись лише на unit-файлах та systemd. Таке рішення негативно вплине на порти, які не використовують ядро Linux (, и ), але в основному архіві подібних портів поки немає і вони не мають статусу .
Прив'язка до systemd також суттєво ускладнить зміну напряму розвитку дистрибутива у майбутньому та обмежить проведення подальших експериментів у галузі ініціалізації та управління сервісами. Підтримувати elogind в робочому вигляді значно простіше, ніж видалити, а потім намагатися додати знову. Кожен варіант рішення має плюси і мінуси, тому перед голосуванням буде потрібно всебічне обговорення всіх аргументів за і проти.
Джерело: opennet.ru