Sam Hartman, Lider Projektu Debian, aby zrozumieć nieporozumienia związane z dostarczaniem pakietu elogind w ramach dystrybucji. W lipcu zespół odpowiedzialny za przygotowanie wydań włączenie elogindu do gałęzi testowej, ponieważ ten pakiet koliduje z libsystemd.
Przypomnijmy, że zapewnia interfejsy potrzebne do uruchomienia GNOME bez instalowania systemd. Projekt powstał jako rozwidlenie systemd-logind, umieszczone w oddzielnym pakiecie i uwolnione od wiązania z komponentami systemd. elogind udostępnia między innymi własną wersję biblioteki libelogind, która przejmuje szereg funkcji oferowanych w libsystemd i zastępuje tę bibliotekę podczas instalacji.
Przyczyną zablokowania był konflikt z pakietem systemd i niebezpieczeństwo zastąpienia libsystemd alternatywnym libelogindem, który jest całkowicie niekompatybilny z biblioteką źródłową na poziomie ABI.
Pakiet oznacza elogind jako powodujący konflikt z bibliotekami systemd, ale z natury jest zaprojektowany do działania tylko bez systemd, a konflikt z systemd jest w rzeczywistości korzystny, ponieważ zapobiega przypadkowej instalacji elogind. Z drugiej strony, w obecnej formie, próby aktualizacji konfiguracji z systemd do wersji z sysvinit i elogind za pośrednictwem APT skutkują z niedziałającym APT. Ale nawet jeśli to niedociągnięcie zostanie wyeliminowane, przejście z systemd na elogind pozostanie niemożliwe bez usunięcia już zainstalowanych środowisk użytkowników.
Twórcami eloginda byli dostosować elogind do pracy na standardowym libpam-systemd, bez używania własnej warstwy libpam-elogind. Przejście elogind do libpam-systemd jest utrudnione przez brak wsparcia dla koncepcji plasterków, ale twórcy elogind nie chcą osiągnąć pełnej zgodności z API i dokładnie powtórzyć wszystkie możliwości systemd, ponieważ elogind zapewnia jedynie minimalne funkcjonalność organizowania loginów użytkowników i nie ma na celu replikowania wszystkich podsystemów systemowych.
Rozwiązanie opisanych problemów technicznych powinno zostać rozwiązane na poziomie interakcji pomiędzy zespołem wydającym a opiekunami elogind i systemd, ale lider projektu został zmuszony do interwencji, ponieważ zespoły nie mogły dojść do porozumienia, wspólna praca przerodziła się w konfrontację i rozwiązanie problemu problem znalazł się w ślepym zaułku, w którym każda ze stron miała rację na swój sposób. Według Sama Hartmana sytuacja zbliża się do stanu wymagającego powszechnego głosowania (GR, uchwała ogólna), w którym społeczność zdecyduje o alternatywnych systemach initu i wsparcia dla sysvinit za pomocą elogindu.
Jeśli członkowie projektu zagłosują za dywersyfikacją systemów init, wszyscy opiekunowie będą zaangażowani we wspólną pracę nad rozwiązaniem tego problemu lub do pracy nad tym problemem zostaną przydzieleni konkretni programiści, a opiekunowie nie będą już mogli ignorować alternatywnego systemu init, milczeć lub opóźnić proces.
Obecnie już w repozytorium 1033, które dostarczają jednostki usługowe dla systemd, ale nie zawierają skryptów init.d. By rozwiązać ten problem domyślnie dostarczaj pliki usług, ale przygotuj moduł obsługi, który automatycznie analizuje polecenia z tych plików i generuje na ich podstawie skrypty init.d.
Jeśli społeczność uzna, że Debian ma wystarczające wsparcie dla pojedynczego systemu init, nie możemy już martwić się o sysvinit i elogind i skupić się tylko na plikach jednostkowych i systemd. Ta decyzja będzie miała negatywny wpływ na porty, które nie korzystają z jądra Linuksa (, и ), ale w głównym archiwum nie ma jeszcze takich portów i nie mają one statusu .
Powiązanie z systemd znacznie utrudni także zmianę kierunku dystrybucji w przyszłości i ograniczy dalsze eksperymenty w zakresie inicjalizacji i zarządzania usługami. Utrzymanie elogindu w działającej formie jest znacznie łatwiejsze niż jego usunięcie i ponowna próba dodania. Każda opcja decyzyjna ma zalety i wady, dlatego przed głosowaniem wymagane będzie pełne omówienie wszystkich za i przeciw.
Źródło: opennet.ru