Schlagwort: Systemd

Es vergeht kein Jahr, in dem es bei Debian nicht mindestens eine Diskussion über Systemd gibt, das bei der Distribution seit 2014 das Standard-Init-System ist. Die Entscheidung für Systemd traf damals nach langen und hitzigen Diskussionen Debians Technisches Komitee (CTTE).

Seitdem gab es viele Diskussionen über die Unterstützung alternativer Init-Systeme, die letztes Jahr in einer Grundsatzentscheidung (General Resolution, GR) gipfelten. Gewonnen hat die Abstimmung damals Option 2 „B: Systemd but we support exploring alternatives“ des damaligen Debian-Projektleiters Sam Hartman:

Das Debian-Projekt erkennt an, dass Systemd Service-Einheiten die bevorzugte Konfiguration sind, um zu beschreiben, wie man einen Daemon/Dienst startet. Dennoch bleibt Debian eine Umgebung, in der Entwickler und Benutzer alternative Init-Systeme und Alternativen zu Systemd erforschen und entwickeln können. Diejenigen, die daran interessiert sind, solche Alternativen zu erforschen, müssen die notwendigen Entwicklungs- und Paketierungs-Ressourcen zur Verfügung stellen, um diese Arbeit zu erledigen.

General Resolution missachtet?

Das scheinen nicht alle Entwickler so zu sehen, denn nun kommt ein Fall vor das CTTE, bei dem der Maintainer des Pakets NetworkManager nach Meinung anderer Entwickler diese Grundsatzentscheidung missachtet und damit den Zugang zu anderen Init-Systemen erschwert oder gar verhindert.

Init-Script entfernt

Es begann mit einem Bugreport aus dem Sommer, der moniert, dass Michael Biebl, der maßgeblich die Integration von Systemd in Debian vorangetrieben hat und immer noch betreut, ein Init-Script aus dem von ihm betreuten Paket NetworkManager entfernt hatte, dass die Nutzung alternativer Init-Systeme ermöglichte. Da NetworkManager ein essenzielles Paket für viele Anwender ist, versucht der Bugreport, die Entfernung rückgängig zu machen.

network-manager (1.25.91-1) unstable; urgency=medium

  * New upstream version 1.25.91 (1.26 rc2)
  * Remove SysV init script

 -- Michael Biebl <[…]>  Thu, 02 Jul 2020 01:17:08 +0200

Das Technische Komitee entscheidet

Da Biebl aber über Monate nicht im Sinne der Befürworter des Init-Scripts reagierte, versuchte es ein Entwickler über das in dem Fall ungeeignete Mittel eines NonMaintainerUpload (NMU), die Änderung rückgängig zu machen. Dem widersprach Biebl. In letzter Konsequenz wendet sich Entwickler Matthew Vernon jetzt an das CTTE, Debians höchste technische Instanz, um den Fall klären zu lassen. Die Frage im entsprechenden Bugreport an das Komitee lautet: »Sollten Maintainer in der Lage sein, Änderungen der Init-Kompatibilität zu blockieren?«

Vernon möchte damit nicht nur das Init-Script in NetworkManager zurück an seinen Platz, sondern generell eine Entscheidung, die verhindert, dass Maintainer Debians Init-Freiheit behindern, es sei denn, der Grund ist ein kaputtes Paket. Vernon wünscht sich eine Entscheidung, die sich bereits auf Debian 11 »Bullseye« auswirkt.

Im Debian-Projekt tritt keine Ruhe ein, wenn es um Init-Systeme geht. 2014 entschied der Technische Ausschuss als letzte Instanz nach andauernden heftigen Debatten, dass fortan Systemd als Standard-Init-System bei Debian verwendet wird. Jetzt sind nach wiederum anhaltenden Diskussionen die Debian-Entwickler zu einer Urabstimmung aufgerufen, die die Frage klären soll, wie sich Debian künftig zu alternativen Init-Systemen stellt. Bei Debian heißt eine solche Urabstimmung General Resolution (GR).

Systemd und kein Ende

Dazu hat der derzeitige Debian-Projektleiter (DPL) Sam Hartman aus den Diskussionen drei Vorschläge erarbeitet, die von anderen Entwicklern mittlerweile auf sieben Vorschläge erweitert wurden. Die darin vorgeschlagenen Richtlinien reichen von »strikt nur noch Systemd« über »auch andere Init-Systeme, wenn sie nicht ausbremsen« bis zu »zwingend auch andere Init-Systeme«.

Urabstimmung über Init-Systeme

Hartman möchte die Entscheidung hinter sich bringen, da solche Diskussionen dazu tendieren, das Projekt zu lähmen. Er hielt lediglich die Mindestdiskussionszeit ein, die Abstimmung beginnt am 7.12 und endet am 27.12. Wegen der Komplexität der Vorschläge wurde die Wahlperiode von den üblichen zwei auf drei Wochen verlängert.

Verschiedene Positionen

Die Vorschläge, die auf dem Stimmzettel auftauchen sind von 1–7 durchnummeriert, wobei DPL Hartman seinen dritten Vorschlag zurückgezogen hat, da die Aussage in anderen Vorschlägen bereits aufgeführt war. Sie stellen die verschiedenen Positionen dar, die sich in der Diskussion auf der Mailingliste herauskristallisiert haben.

Die Vorschläge

Vorschlag 1 stammt von Martin Michlmayr, der die Fokussierung auf Systemd festschreiben möchte und es damit Paketen ermöglicht, ausschließlich Systemd-Funktionen zu nutzen. Alternative Systeme sind willkommen, sollten aber die Entwicklung nicht aufhalten.

Vorschlag 2 wurde von Hartman formuliert und ist mit »Systemd, aber wir unterstützen die Suche nach Alternativen« überschrieben. Debian würde damit anerkennen, dass Systemd-Service-Einheiten die bevorzugte Konfiguration sind, um zu beschreiben, wie man einen Daemon oder Dienst startet. Debian bleibt damit jedoch weiterhin eine Umgebung, in der Entwickler und Benutzer alternative Init-Systeme und Alternativen zu Systemfunktionen erforschen und entwickeln können. Zudem betont der Vorschlag das Bekenntnis Debians zur Zusammenarbeit mit Derivaten, die unterschiedliche Entscheidungen über Init-Systeme treffen.

Vorschlag 3 ist mit »Unterstützung mehrerer Init-Systeme ist wichtig« überschrieben und besagt, alle Pakete müssen auch ohne Systemd funktionieren, sofern der Entwickler sie nicht ausdrücklich auf Systemd beschränkt hat. Steht ein Paket nicht für mehrere Init-System bereit, wäre das ein Fehler, der mit importantzu klassifizieren wäre.

Vorschlag 4 stammt von Debian-Urgestein Ian Jackson und mit »Unterstützung von nicht Systemd-gebundenen Systemen, ohne den Fortschritt zu blockieren«. Der sehr ausführliche Vorschlag sieht vor, dass Pakete auf nicht Systemd-gebundenen Installationen funktionieren, aber ein Fehlverhalten gilt nicht als veröffentlichungskritischer Fehler – es sei denn, es gibt die notwendige Unterstützung, wurde aber vom Paketbetreuer nicht aktiviert. Die Verwendung von Systemd-spezifischen Funktionen ist nur zulässig, wenn diese Funktionen dokumentiert sind und alternative Implementierungen realisierbar sind.

Vorschlag 5 von Dmitry Bogatov lässt bereits in der Überschrift erkennen, dass Bogatov unterschiedliche Init-Systeme als verbindlich festgeschrieben sehen möchte. Nach seiner Ansicht muss jedes Paket auch mit Init-Alternativen zu Systemd funktionieren.

Vorschlag 6 stammt von Guillem Jover und ist mit »Unterstützt Portabilität und mehrere Implementierungen« überschrieben. Dieser Vorschlag bleibt vage und sagt lediglich, dass Hard- und Software wichtig sind, aber keine spezifischen Hinweise darauf gibt, was das für die Projektpolitik bedeuten würde. Option 7 steht bisher noch nicht auf der Webseite, stammt wiederum von Ian Jackson, der darin die Vorschläge 4 und 6 zusammenfasst und weiter ausarbeitet.

Stimmberechtigt

Alle rund 1.000 offiziellen Debian-Entwickler sind stimmberechtigt und können sich für einen der Vorschläge entscheiden oder dafür stimmen, das Problem zurück an den Diskussionstisch zu schicken. Da mittlerweile viele Entwickler von der anstrengenden Diskussion genervt sind, wird es aber vermutlich zu einer Entscheidung kommen, die dann in die Richtlinien der Debian Policy einfließen.