Сэм Хартман (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