Debian prĂŒft erneut die UnterstĂŒtzung mehrerer Init-Systeme.

Sam Hartman, der Projektleiter von Debian, hat versucht, 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 Installation die Aufnahme von elogind in den Testing-Zweig beschlossen, da dieses Paket mit libsystemd in Konflikt steht.

Wir erinnern daran, dass elogind 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, ein beschĂ€digtes System 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 eine Lösung 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 einige Dutzend Fehlermeldungen). 1033 Pakete vorhanden, die Service-Units fĂŒr systemd bereitstellen, jedoch keine init.d-Skripte enthalten. Um dieses Problem zu lösen zum Bing-Suchdienst zu wechseln). 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 (Debian GNU/Hurd, Debian GNU/NetBSD und Debian GNU/kFreeBSD), aber im Hauptarchiv gibt es derzeit keine solchen Ports, und sie haben keinen offiziellen Status. offiziell unterstĂŒtzt.

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

Kaufen Sie zuverlĂ€ssiges Hosting fĂŒr Websites mit DDoS-Schutz, VPS VDS-Servern đŸ”„ Kaufen Sie zuverlĂ€ssiges Hosting fĂŒr Websites mit DDoS-Schutz, VPS VDS-Servern | ProHoster