Die Ergebnisse der Abstimmung über Init-Systeme in Debian wurden zusammengefasst

Veröffentlicht Ergebnisse allgemeine Abstimmung (GR, allgemeine Resolution) der Entwickler des Debian-Projekts, die an der Pflege von Paketen und der Unterstützung der Infrastruktur beteiligt sind, wurde zu dem Thema der Unterstützung mehrerer Initialisierungssysteme durchgeführt. Der zweite Punkt („B“) in der Liste gewann — der bevorzugte Anbieter bleibt systemd, aber die Möglichkeit zur Unterstützung alternativer Initialisierungssysteme wird beibehalten. Die Abstimmung erfolgte nach der Kondorc-Methode, bei der jeder Wähler alle Optionen in der Reihenfolge seiner Präferenzen rangiert, und bei der Berechnung des Ergebnisses wird berücksichtigt, wie viele Wähler eine Option einer anderen vorziehen.

Die gewählte Option erkennt an, dass die Serviceeinheiten von systemd die bevorzugte Methode zur Konfiguration des Starts von Daemons und Diensten darstellen, lässt jedoch zu, dass es Umgebungen gibt, in denen Entwickler und Benutzer alternative Initialisierungssysteme und funktionale Alternativen zu den Möglichkeiten von systemd erstellen und anwenden können. Entwickler alternativer Lösungen benötigen Ressourcen zur Durchführung ihrer Arbeit und zur Formatierung von Paketen. Alternative Lösungen, wie elogind, die zur Organisation des Starts von an systemd-spezifischen Schnittstellen gebundenen Anwendungen verwendet werden, bleiben für das Projekt wichtig. Die Unterstützung solcher Initiativen erfordert Kooperation in Bereichen, in denen die entwickelten alternativen Technologien mit dem Rest des Projekts zusammentreffen, zum Beispiel ist ein verzögerndes Überprüfen von Patches und das Führen von Diskussionen nicht akzeptabel.

In Pakete können sowohl unit-Dateien von systemd als auch Init-Skripte zum Starten von Diensten aufgenommen werden. Pakete dürfen die Funktionen von systemd nach Belieben des Paketbetreuers nutzen, sofern diese Funktionen den Anforderungen der Debian-Regeln entsprechen und nicht an experimentelle oder nicht unterstützte Funktionen anderer Pakete in Debian gebunden sind. Neben systemd können Pakete auch Unterstützung für alternative Init-Systeme beinhalten und Komponenten zur Verfügung stellen, um spezifische systemd-Schnittstellen zu ersetzen. Entscheidungen über die Einbeziehung von Patches treffen die Paketbetreuer im Rahmen der regulären Verfahren. Debian verpflichtet sich, mit abgeleiteten Distributionen zusammenzuarbeiten, die andere Init-Systeme gewählt haben, aber die Interaktion erfolgt auf Betreuungsebene, auf der die Entscheidungen darüber fallen, welche von externen Distributionen vorbereiteten Funktionen in den Hauptbestand von Debian aufgenommen werden und welche in der abgeleiteten Distribution bleiben.

Wir erinnern daran, dass der technische Ausschuss genehmigte der Wechsel von 2014 standardmäßig auf systemd umschaltete, jedoch nicht entschied über die Unterstützung mehrerer Init-Systeme (beim Abstimmen gewann der Punkt, der auf die Unfähigkeit des Ausschusses hinweist, eine Entscheidung zu diesem Thema zu treffen). Der Vorsitzende des Ausschusses empfahl den Paketbetreuern, die Unterstützung für sysvinit als alternatives Init-System beizubehalten, stellte jedoch klar, dass er seine Meinung nicht aufzwingen kann und in jedem Fall selbst entschieden werden muss.

Nach diesem Zeitpunkt unternahmen einige Entwickler den Versuch, eine allgemeine Abstimmung durchzuführen, jedoch zeigte die vorläufige Abstimmung, dass keine Notwendigkeit für eine Entscheidung über die Verwendung mehrerer Init-Systeme bestand. Vor einigen Monaten, nach der Probleme der Einspeisung des Pakets elogind (das für den Betrieb von GNOME ohne systemd erforderlich ist) in den Testing-Zweig aufgrund eines Konflikts mit libsystemd, wurde die Frage erneut vom Projektleiter von Debian aufgebracht, da die Entwickler sich nicht einigen konnten und ihre Kommunikation in einen Konflikt umschlug und in eine Sackgasse führte.

Die betrachteten Optionen:

Der Fokus liegt auf systemd. Die Bereitstellung von Unterstützung für alternative Init-Systeme hat keine Priorität, aber die Maintainer können optional Init-Skripte für solche Systeme in die Pakete einfügen.

Bevorzugt wird systemd, aber es bleibt die Möglichkeit, alternative Init-Systeme zu unterstützen. Technologien wie elogind, die es ermöglichen, Anwendungen in alternativen Umgebungen zu starten, die an systemd gebunden sind, werden als wichtig erachtet. Init-Dateien für alternative Systeme dürfen in die Pakete aufgenommen werden.

Unterstützung für verschiedene Init-Systeme und die Möglichkeit, Debian mit Init-Systemen zu starten, die sich von systemd unterscheiden.
Um Dienste zu starten, müssen die Pakete Init-Skripte enthalten; die Bereitstellung nur von systemd-Unit-Dateien ohne sysv Init-Skripte ist nicht zulässig.

Unterstützung von Systemen, die systemd nicht verwenden, jedoch ohne Änderungen, die die Entwicklung behindern. Die Entwickler stimmen zu, mehrere Init-Systeme in der absehbaren Zukunft zu unterstützen, halten es aber auch für notwendig, an einer Verbesserung der Unterstützung für systemd zu arbeiten. Die Entwicklung und Pflege spezifischer Lösungen sollte durch Interessengruppen erfolgen, die an solchen Lösungen interessiert sind, aber andere Maintainer sollten aktiv helfen und Probleme lösen, wenn dies erforderlich ist. Idealerweise sollten die Pakete mit jedem Init-System funktionieren, wofür traditionell Init-Skripte bereitgestellt oder alternative Mechanismen verwendet werden können, die ein Arbeiten ohne systemd ermöglichen. Die Unmöglichkeit, ohne systemd zu arbeiten, wird als Fehler betrachtet, jedoch nicht als Fehler, der die Veröffentlichung blockiert, es sei denn, es gibt eine fertige Lösung für das Arbeiten ohne systemd, die jedoch nicht beibehalten wird (zum Beispiel, wenn das Problem durch das Entfernen eines zuvor bereitgestellten Init-Skripts verursacht wird).

Unterstützung der Portabilität ohne Änderungen, die die Entwicklung beeinträchtigen. Debian wird weiterhin als Bindeglied für die Integration verschiedener Software betrachtet, die äquivalente oder ähnliche Funktionalitäten bietet. Portabilität zwischen Hardware-Plattformen und Software-Stacks gehört zu den wichtigen Aufgaben, und die Integration alternativer Technologien wird begrüßt, auch wenn die Weltanschauung ihrer Schöpfer von der allgemeinen Meinung abweicht. Die Haltung gegenüber systemd und anderen Init-Systemen stimmt vollständig mit Punkt 4 überein.

Umwandlung der Unterstützung mehrerer Init-Systeme in eine Verpflichtung. Die Möglichkeit, Debian mit Init-Systemen zu starten, die sich von systemd unterscheiden, bleibt für das Projekt wichtig. Jedes Paket muss mit pid1-Handlern arbeiten, die sich von systemd unterscheiden, es sei denn, die in das Paket aufgenommene Software ist ursprünglich nur für den Einsatz mit systemd vorgesehen und es gibt keine Unterstützung für den Start ohne systemd (das Fehlen von Init-Skripten wird nicht als ausschließlich für den Einsatz mit systemd gedacht angesehen).

Unterstützung für Portabilität und mehrere Implementierungen. Die allgemeinen Prinzipien stimmen vollständig mit Punkt 5 überein, aber es gibt keine spezifischen Anforderungen an systemd und Init-Systeme, und es werden auch keine Verpflichtungen für die Entwickler auferlegt. Den Entwicklern wird geraten, die Interessen des jeweils anderen zu berücksichtigen, Kompromisse einzugehen und gemeinsame Lösungen zu finden, die für verschiedene Parteien zufriedenstellend sind.

Fortsetzung der Diskussion. Der Punkt kann genutzt werden, um die Bewertung unakzeptabler Optionen zu senken.

Quelle: opennet.ru