Sam Hartman, lider projektu Debian, rozwiązać nieporozumienia dotyczące dostarczenia pakietu elogind jako części dystrybucji. W lipcu zespół odpowiedzialny za przygotowanie wydań włączenie elogind do gałęzi testing, ponieważ pakiet ten stoi w konflikcie z libsystemd.
Przypomnijmy, że zapewnia interfejsy niezbędne do działania GNOME bez instalacji systemd. Projekt powstał jako odgałęzienie systemd-logind, wyodrębnione w osobny pakiet i pozbawione powiązania z komponentami systemd. Elogind dostarcza również swoją wersję biblioteki libelogind, która przejmuje szereg funkcji oferowanych przez libsystemd i zastępuje tę bibliotekę podczas instalacji.
Jako powód blokady wskazano konflikt z pakietem systemd oraz ryzyko zastąpienia libsystemd alternatywną wersją libelogind, która jest całkowicie niekompatybilna z pierwotną biblioteką na poziomie ABI.
Pakiet elogind oznaczony jest jako konfliktujący z bibliotekami systemd, ale sam w sobie zaprojektowany jest do pracy tylko bez systemd, a konflikt z systemd nawet przynosi korzyść, ponieważ uniemożliwia przypadkową instalację elogind. Z drugiej strony, w obecnej formie, próby aktualizacji konfiguracji z systemd na wersję z sysvinit i elogind poprzez APT prowadzą do uzyskania z nie działającym APT. Jednak nawet po usunięciu tej niedoróbki, przejście z systemd na elogind pozostaje niemożliwe bez usunięcia już zainstalowanych środowisk użytkowników.
Deweloperzy elogind byli zmuszeni do zaadaptowania elogind do pracy na bazie standardowego libpam-systemd, bez użycia własnej warstwy libpam-elogind. Przejściu elogind na libpam-systemd przeszkadza brak wsparcia dla koncepcji slice'ów, ale deweloperzy elogind nie chcą dążyć do pełnej zgodności API ani dokładnego powtórzenia wszystkich możliwości systemd, ponieważ elogind tylko zapewnia minimalną funkcjonalność do organizacji logowania użytkowników i nie ma na celu powtarzania wszystkich podsystemów systemd.
Rozwiązanie opisanych problemów technicznych powinno być podejmowane na poziomie współpracy zespołu wydania i opiekunów elogind i systemd, ale lider projektu musiał interweniować, ponieważ zespoły nie mogły dojść do porozumienia, wspólna praca przekształciła się w konfrontację, a rozwiązanie problemu utknęło w martwym punkcie, w którym każda strona ma swoje racje. Zdaniem Sama Hartmana, sytuacja zbliża się do stanu wymagającego przeprowadzenia ogólnego głosowania (GR, general resolution), w którym społeczność podejmie decyzję w sprawie alternatywnych systemów inicjalizacji oraz wsparcia sysvinit z elogind.
Jeśli uczestnicy projektu zagłosują za dywersyfikacją systemów inicjalizacji, wszyscy opiekunowie zostaną zaangażowani we współpracę nad rozwiązaniem tego problemu lub zostaną wyznaczeni specjalni odpowiedzialni deweloperzy do pracy nad tą sprawą, a opiekunowie nie będą mogli dłużej ignorować alternatywnego systemu inicjalizacji, milczeć ani opóźniać procesu.
Obecnie w repozytorium już 1033 pakiety, dostarczające jednostki serwisowe dla systemd, ale nie zawierające skryptów init.d. Aby rozwiązać ten problem, należy dostarczać domyślnie pliki service, ale przygotować program, który automatycznie analizowałby polecenia z tych plików i na ich podstawie generowałby skrypty init.d.
Jeśli społeczność zdecyduje, że w Debianie wystarcza wsparcie dla jednego systemu inicjalizacji, nie trzeba będzie więcej martwić się o sysvinit i elogind, koncentrując się wyłącznie na plikach jednostek i systemd. Takie rozwiązanie negatywnie wpłynie na porty, które nie używają jądra Linux (, i ), ale w głównym archiwum podobnych portów na razie nie ma i nie mają one statusu .
Związanie z systemd znacznie utrudni również zmianę kierunku rozwoju dystrybucji w przyszłości i ograniczy dalsze eksperymenty w dziedzinie inicjalizacji i zarządzania usługami. Utrzymywanie elogind w działającym stanie jest zdecydowanie prostsze niż usunięcie go, a następnie próba ponownego dodania. Każda z opcji rozwiązania ma swoje plusy i minusy, dlatego przed głosowaniem będzie potrzebna wszechstronna dyskusja nad wszystkimi argumentami za i przeciw.
Źródło: opennet.ru
