Sam Hartman, Debian-Projektleiter, um die Meinungsverschiedenheiten zu verstehen, die mit der Lieferung des elogind-Pakets als Teil der Distribution verbunden sind. Im Juli das Team, das für die Vorbereitung der Veröffentlichungen verantwortlich ist Aufnahme von elogind in den Testzweig, da dieses Paket mit libsystemd in Konflikt steht.
Daran erinnern, dass stellt die Schnittstellen bereit, die zum Ausführen von GNOME ohne Installation von systemd erforderlich sind. Das Projekt wurde als Fork von systemd-logind gegründet, in einem separaten Paket untergebracht und von der Bindung an systemd-Komponenten befreit. elogind stellt unter anderem eine eigene Version der libelogind-Bibliothek zur Verfügung, die eine Reihe von in libsystemd angebotenen Funktionen übernimmt und diese Bibliothek bei der Installation ersetzt.
Gründe für die Blockierung waren ein Konflikt mit dem systemd-Paket und die Gefahr, libsystemd durch ein alternatives libelogind zu ersetzen, das auf ABI-Ebene völlig inkompatibel mit der Quellbibliothek ist.
Das Paket kennzeichnet elogind als Konflikt mit Systemd-Bibliotheken, ist aber von Natur aus darauf ausgelegt, nur ohne Systemd zu funktionieren, und ein Konflikt mit Systemd ist tatsächlich von Vorteil, da er verhindert, dass Elogind versehentlich installiert wird. Andererseits führen Versuche über APT, die Konfiguration von systemd auf die Version mit sysvinit und elogind zu aktualisieren, in der aktuellen Form zu mit APT funktioniert nicht. Aber selbst wenn dieser Mangel behoben wird, bleibt der Übergang von systemd zu elogind ohne das Löschen bereits installierter Benutzerumgebungen unmöglich.
Die elogind-Entwickler waren Passen Sie elogind an, um auf dem Standard-libpam-systemd zu arbeiten, ohne eine eigene libpam-elogind-Ebene zu verwenden. Der Übergang von elogind zu libpam-systemd wird durch die fehlende Unterstützung des Slice-Konzepts erschwert, die Entwickler von elogind möchten jedoch keine vollständige Konformität mit der API erreichen und alle Funktionen von systemd exakt wiederholen, da elogind nur minimale Funktionen bietet Funktionalität zum Organisieren von Benutzeranmeldungen und zielt nicht darauf ab, alle systemd-Subsysteme zu replizieren.
Die Lösung der beschriebenen technischen Probleme sollte auf der Ebene der Interaktion zwischen dem Release-Team und den elogind- und systemd-Betreuern gelöst werden, aber der Projektleiter war gezwungen einzugreifen, weil sich die Teams nicht einigen konnten, die gemeinsame Arbeit sich zu einer Konfrontation entwickelte und die Lösung für das Das Problem gelangte in eine Sackgasse, in der jede Seite auf ihre Weise Recht hatte. Laut Sam Hartman nähert sich die Situation einem Zustand, der eine allgemeine Abstimmung (GR, General Resolution) erfordert, in der die Community über alternative Systeme für Init und die Unterstützung von Sysvinit mit Elogind entscheiden wird.
Wenn Projektmitglieder für die Diversifizierung von Init-Systemen stimmen, werden alle Betreuer in die Zusammenarbeit zur Lösung dieses Problems einbezogen oder bestimmte Entwickler werden mit der Arbeit an diesem Problem beauftragt, und Betreuer können ein alternatives Init-System nicht länger ignorieren, schweigen oder schweigen den Prozess verzögern.
Derzeit bereits im Repository 1033 Pakete, die Serviceeinheiten für systemd bereitstellen, aber keine init.d-Skripte enthalten. Um dieses Problem zu lösen Stellen Sie standardmäßig Servicedateien bereit, bereiten Sie jedoch einen Handler vor, der automatisch Befehle aus diesen Dateien analysiert und darauf basierend init.d-Skripte generiert.
Wenn die Community entscheidet, dass Debian genügend Unterstützung für ein einzelnes Init-System bietet, können wir uns nicht mehr um Sysvinit und Elogind kümmern und uns nur auf Unit-Dateien und Systemd konzentrieren. Diese Entscheidung wird sich negativ auf Ports auswirken, die nicht den Linux-Kernel verwenden (, и ), aber es gibt noch keine solchen Ports im Hauptarchiv und sie haben nicht den Status .
Durch die Bindung an systemd wird es in Zukunft auch deutlich schwieriger, die Richtung der Verteilung zu ändern, und weitere Experimente im Bereich Initialisierung und Service-Management werden eingeschränkt. Es ist viel einfacher, elogind funktionsfähig zu halten, als es zu löschen und dann erneut zu versuchen, es hinzuzufügen. Jede Entscheidungsoption hat Vor- und Nachteile, daher ist vor der Abstimmung eine ausführliche Diskussion aller Vor- und Nachteile erforderlich.
Source: opennet.ru