Sam Hartman, der Projektleiter von Debian, die Uneinigkeiten bezüglich der Bereitstellung des Paket elogind im Distribution zu klären. Im Juli hat das Team, das für die Erstellung der Releases verantwortlich ist, die Aufnahme von elogind in den Testing-Zweig beschlossen, da dieses Paket mit libsystemd in Konflikt steht.
Wir erinnern daran, dass Es bietet die notwendigen Schnittstellen für die Nutzung von GNOME ohne die Installation von systemd. Das Projekt entstand als Abspaltung von systemd-logind, das in ein eigenes Paket ausgegliedert wurde und von den Komponenten von systemd entkoppelt ist. Unter anderem bietet elogind seine eigene Version der Bibliothek libelogind an, die eine Reihe von Funktionen übernimmt, die in libsystemd angeboten werden, und ersetzt bei der Installation diese Bibliothek.
Als Gründe für die Blockierung wurde der Konflikt mit dem Paket systemd und die Gefahr der Ersetzung von libsystemd durch die alternative Version libelogind, die auf ABI-Ebene vollständig inkompatibel ist, angeführt.
Das Paket elogind ist als konfliktbehaftet mit den systemd-Bibliotheken gekennzeichnet, ist jedoch grundsätzlich nur für die Verwendung ohne systemd ausgelegt, und der Konflikt mit systemd ist tatsächlich vorteilhaft, da er die fehlerhafte Installation von elogind verhindert. Andererseits führen im aktuellen Zustand die Versuche, die Konfiguration über APT von systemd auf eine Variante mit sysvinit und elogind zu aktualisieren, dazu, mit nicht funktionierendem APT zu erhalten. Doch selbst nach Behebung dieses Fehlers bleibt der Übergang von systemd zu elogind ohne die Deinstallation bereits installierter Benutzerumgebungen unmöglich.
Die Entwickler von elogind haben elogind zur Verwendung mit der standardmäßigen libpam-systemd anzupassen, ohne eine eigene Schicht namens libpam-elogind zu verwenden. Der Übergang von elogind zu libpam-systemd wird durch das Fehlen der Unterstützung des Slice-Konzepts behindert, aber die Entwickler von elogind sind nicht daran interessiert, eine vollständige Übereinstimmung mit der API zu erreichen und alle Funktionen von systemd exakt zu reproduzieren, da elogind nur die grundlegende Funktionalität zur Organisation des Benutzeranmeldens bereitstellt und nicht darauf abzielt, alle Subsysteme von systemd nachzubilden.
Die Lösung der beschriebenen technischen Probleme sollte auf der Ebene der Zusammenarbeit zwischen dem Release-Team und den Maintainern von elogind und systemd angegangen werden. Doch der Projektleiter sah sich gezwungen einzugreifen, da die Teams nicht zu einer Einigung kommen konnten. Die Zusammenarbeit war in ein Gegeneinander umgeschlagen, und die Problemlösung hatte einen Stillstand erreicht, in dem jede Seite ihren Standpunkt für richtig hielt. Laut Sam Hartman nähert sich die Situation einem Zustand, der ein allgemeines Abstimmungsverfahren (GR, general resolution) erforderlich macht, in dem die Gemeinschaft über alternative Init-Systeme und die Unterstützung von sysvinit mit elogind entscheidet.
Wenn die Projektteilnehmer für die Diversifizierung der Init-Systeme stimmen, werden alle Maintainer in die Zusammenarbeit zur Lösung dieser Aufgabe einbezogen oder es werden spezielle verantwortliche Entwickler für diese Herausforderung ernannt. Die Beteiligten können die alternative Init-Schicht dann nicht mehr ignorieren, schweigen oder die Prozesse verlangsamen.
Derzeit sind im Repository bereits 1033 Pakete vorhanden, die Service-Units für systemd bereitstellen, jedoch keine init.d-Skripte enthalten. Um dieses Problem zu lösen Standardmäßig Service-Dateien bereitstellen, aber einen Handler vorbereiten, der automatisch Befehle aus diesen Dateien parst und auf deren Grundlage init.d-Skripte generiert.
Wenn die Community entscheidet, dass Debian ausreichend Unterstützung für ein Init-System bietet, kann die Pflege von sysvinit und elogind aufgegeben werden, um sich nur auf die Unit-Dateien und systemd zu konzentrieren. Eine solche Entscheidung würde sich negativ auf die Ports auswirken, die nicht den Linux-Kernel verwenden (, und ), aber im Hauptarchiv gibt es derzeit keine solchen Ports, und sie haben keinen offiziellen Status. .
Die Bindung an systemd wird es auch erheblich erschweren, die Entwicklungsrichtung der Distribution in Zukunft zu ändern und weitere Experimente im Bereich der Initialisierung und Serviceverwaltung durchzuführen. Es ist viel einfacher, elogind funktionsfähig zu halten, als es zu entfernen und später wieder hinzuzufügen. Jede Lösung hat ihre Vor- und Nachteile, daher ist eine umfassende Diskussion über alle Argumente für und gegen die Abstimmung notwendig.
Quelle: opennet.ru
