Sam Hartman, der Projektleiter von Debian, die Meinungsverschiedenheiten zu klĂ€ren, die mit der Bereitstellung des Pakets elogind im Distribution zusammenhĂ€ngen. Im Juli blockierte das Team, das fĂŒr die Vorbereitung der Releases verantwortlich ist, EinfĂŒhrung von elogind in den Testing-Zweig, da dieses Paket mit libsystemd in Konflikt steht.
Wir erinnern daran, dass bietet die Schnittstellen, die erforderlich sind, um GNOME ohne Installation von systemd zum Laufen zu bringen. Das Projekt entstand als Abspaltung von systemd-logind, die in ein separates Paket ĂŒberfĂŒhrt wurde und von der Bindung an die Komponenten von systemd befreit ist. DarĂŒber hinaus bietet elogind seine eigene Version der Bibliothek libelogind an, die eine Reihe von Funktionen ĂŒbernimmt, die in libsystemd angeboten werden, und diese Bibliothek bei der Installation ersetzt.
Zu den GrĂŒnden fĂŒr die Blockierung wurde der Konflikt mit dem Paket systemd und die Gefahr der Ersetzung von libsystemd durch die alternative Version libelogind angefĂŒhrt, die vollstĂ€ndig inkompatibel mit der ursprĂŒnglichen Bibliothek auf ABI-Ebene ist.
Das Paket elogind wird als konflikttrĂ€chtig mit den Bibliotheken von systemd gekennzeichnet, ist jedoch grundsĂ€tzlich darauf ausgelegt, nur ohne systemd zu arbeiten, und der Konflikt mit systemd bringt sogar Vorteile, da er eine versehentliche Installation von elogind verhindert. Andererseits fĂŒhren aktuelle Versuche, ĂŒber APT die Konfiguration von systemd auf die Variante mit sysvinit und elogind umzustellen, zu einem mit einem nicht funktionierenden APT. Doch selbst bei Beseitigung dieses Problems bleibt der Ăbergang von systemd zu elogind ohne die Deinstallation bereits installierter Benutzerumgebungen unmöglich.
Die Entwickler von elogind wurde elogind so anzupassen, dass es auf dem standardmĂ€Ăigen libpam-systemd lĂ€uft, ohne eine eigene Schicht libpam-elogind zu nutzen. Der Ăbergang von elogind zu libpam-systemd wird durch die fehlende UnterstĂŒtzung des Konzepts der Slices behindert, doch die Entwickler von elogind streben nicht an, die API vollstĂ€ndig zu harmonisieren oder alle Funktionen von systemd exakt zu reproduzieren, da elogind lediglich minimale FunktionalitĂ€ten zur Benutzeranmeldung bereitstellt und nicht das Ziel verfolgt, alle Subsysteme von systemd zu duplizieren.
Die Lösung der beschriebenen technischen Probleme sollte auf der Ebene der Zusammenarbeit des Release-Teams und der Maintainer von elogind und systemd erfolgen, jedoch musste der Projektleiter eingreifen, da sich die Teams nicht einigen konnten. Die Zusammenarbeit entwickelte sich zu einem Konfrontation und die Problemlösung geriet in eine Sackgasse, in der jede Seite auf ihre Weise recht hat. Sam Hartman ist der Meinung, dass die Situation einen Zustand erreicht, der eine allgemeine Abstimmung (GR, general resolution) erfordert, in der die Gemeinschaft eine Entscheidung ĂŒber alternative Init-Systeme und die UnterstĂŒtzung von sysvinit mit elogind trifft.
Wenn die Projektteilnehmer fĂŒr die Diversifizierung der Init-Systeme abstimmen, werden alle Maintainer in die gemeinsame Arbeit zur Lösung dieser Aufgabe einbezogen oder es werden spezielle verantwortliche Entwickler fĂŒr diese Problematik benannt, und die Begleiter können alternative Init-Systeme nicht lĂ€nger ignorieren, sich zurĂŒckhalten oder den Prozess hinauszögern.
Derzeit gibt es bereits 1033 Pakete, die Service-Units fĂŒr systemd bereitstellen, jedoch keine init.d-Skripte enthalten. Um dieses Problem zu lösen, sollten standardmĂ€Ăig Service-Dateien bereitgestellt werden, aber ein Handler vorbereitet werden, der automatisch die Befehle aus diesen Dateien analysiert und basierend darauf init.d-Skripte generiert.
Wenn die Gemeinschaft entscheidet, dass es in Debian ausreicht, eine Init-Anlage zu unterstĂŒtzen, kann man sich mehr auf sysvinit und elogind konzentrieren und nur auf Unit-Dateien und systemd fokussieren. Eine solche Entscheidung wĂŒrde sich negativ auf Ports auswirken, die keinen Linux-Kernel verwenden (, und ), aber im Hauptarchiv gibt es solche Ports bisher nicht und sie haben keinen Status. .
Die Bindung an systemd erschwert es auĂerdem, in Zukunft die Richtung der Distribution zu Ă€ndern und schrĂ€nkt weitere Experimente im Bereich der Initialisierung und des Servicemanagements ein. Es ist erheblich einfacher, elogind in einem funktionierenden Zustand zu halten, als es zu entfernen und dann erneut hinzuzufĂŒgen. Jede Lösung hat ihre Vor- und Nachteile, daher erfordert die Abstimmung eine umfassende Diskussion aller Argumente fĂŒr und gegen.
Quelle: opennet.ru
