Die Ergebnisse der Abstimmung zu den Initialisierungssystemen in Debian wurden bekannt gegeben.

Veröffentlicht die Ergebnisse allgemeine Abstimmung (GR, allgemeine Resolution) der Entwickler des Debian-Projekts, die an der Betreuung der Pakete und der Aufrechterhaltung der Infrastruktur beteiligt sind, die zu der Frage der Unterstützung mehrerer Init-Systeme durchgeführt wurde. Der zweite Punkt («B») in der Liste hat gewonnen — systemd bleibt bevorzugt, aber es wird die Möglichkeit zur Unterstützung alternativer Init-Systeme belassen. Die Abstimmung wurde nach der Methode Condorcetsdurchgeführt, bei der jeder Wähler alle Optionen nach ihrer Präferenz einordnet und bei der Berechnung des Ergebnisses berücksichtigt wird, wie viele Wähler eine Option einer anderen vorziehen.

Die gewinnende Variante erkennt an, dass die Serviceeinheiten von systemd die bevorzugte Methode zur Konfiguration des Starts von Daemons und Diensten darstellen, räumt jedoch ein, dass es Umgebungen gibt, in denen Entwickler und Benutzer alternative Init-Systeme und funktionale Alternativen zu den Möglichkeiten von systemd erstellen und anwenden können. Entwickler alternativer Lösungen benötigen Ressourcen, um ihre Arbeit durchzuführen und Pakete zu formatieren. Alternative Lösungen wie elogind, die zur Organisation des Starts von Anwendungen verwendet werden, die an spezifische systemd-Schnittstellen gebunden sind, bleiben für das Projekt wichtig. Die Unterstützung solcher Initiativen erfordert eine Zusammenarbeit in Bereichen, in denen die entwickelten alternativen Technologien mit dem restlichen Projekt überschneiden, beispielsweise ist es nicht akzeptabel, die Überprüfung von Patches und die Durchführung von Diskussionen zu verzögern.

In Pakete dürfen sowohl systemd-Einheiten als auch Init-Skripte zur Dienstactivation enthalten sein. Die Pakete können nach Belieben des Paketbetreuers sämtliche Funktionen von systemd nutzen, solange diese Funktionen den Anforderungen der Debian-Richtlinien entsprechen und nicht an experimentelle oder nicht unterstützte Funktionen anderer Pakete in Debian gebunden sind. Neben systemd können die Pakete auch Unterstützung für alternative Init-Systeme beinhalten und Komponenten zur Bereitstellung spezifischer Schnittstellen für systemd anbieten. Entscheidungen über die Aufnahme von Patches werden von den Betreuern im Rahmen der Standardverfahren getroffen. Debian verpflichtet sich zur Zusammenarbeit mit abgeleiteten Distributionen, die andere Init-Systeme gewählt haben; die Interaktion erfolgt jedoch auf der Ebene der Betreuer, die die Entscheidungen darüber treffen, welche von Dritten vorbereiteten Funktionen in die Hauptverteilung von Debian aufgenommen werden und welche in der abgeleiteten Distribution verbleiben.

Erinnern wir uns, dass im Jahr 2014 der technische Ausschuss genehmigte Übergang der Standarddistribution zu systemd, jedoch nicht ausgearbeitet hat Lösungen zur Unterstützung mehrerer Init-Systeme (im Abstimmungsergebnis wurde die Option gewählt, die auf die Unfähigkeit des Komitees hinweist, eine Entscheidung zu diesem Thema zu treffen). Der Vorsitzende des Komitees empfahl den Paketbetreuern, die Unterstützung von sysvinit als alternatives Init-System beizubehalten, wies jedoch darauf hin, dass er seine Meinung nicht aufzwingen könne und in jedem Fall die Entscheidung selbst getroffen werden sollte.

Daraufhin unternahmen einige Entwickler einen Versuch, eine allgemeine Abstimmung abzuhalten, aber die vorläufige Abstimmung zeigte, dass kein Bedarf bestand, eine Entscheidung über die Verwendung mehrerer Init-Systeme zu treffen. Vor mehreren Monaten, nach problemen dem Einfügen des Pakets elogind (notwendig für den Betrieb von GNOME ohne systemd) in den Testing-Zweig aufgrund eines Konflikts mit libsystemd, wurde die Frage erneut vom Projektleiter von Debian aufgegriffen, da die Entwickler sich nicht einigen konnten und ihre Kommunikation in ein Gegeneinander überging und in eine Sackgasse führte.

Die betrachteten Optionen:

Der Schwerpunkt liegt auf systemd. Die Bereitstellung von Unterstützung für alternative Init-Systeme hat keine Priorität, aber die Maintainer dürfen optional Init-Skripte für solche Systeme in Pakete aufnehmen.

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

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

Unterstützung von Systemen, die kein systemd verwenden, jedoch ohne Änderungen, die die Entwicklung behindern. Die Entwickler sind bereit, mehrere Init-Systeme in absehbarer Zeit zu unterstützen, halten es jedoch für notwendig, die Unterstützung von systemd zu verbessern. Die Entwicklung und Wartung spezifischer Lösungen sollte von den Gemeinschaften übernommen werden, die an solchen Lösungen interessiert sind, aber andere Maintainer sollten aktiv helfen und zur Lösung von Problemen beitragen, wenn dies erforderlich ist. Ideal wäre es, wenn die Pakete mit jedem Init-System funktionieren, weshalb traditionelle Init-Skripte bereitgestellt oder andere Mechanismen verwendet werden sollten, die einen Betrieb ohne systemd ermöglichen. Die Unfähigkeit, ohne systemd zu arbeiten, wird als Fehler angesehen, jedoch nicht als fehlerhaft, der die Veröffentlichung blockiert, es sei denn, es gibt eine bereitgestellte Lösung für den Betrieb ohne systemd, die jedoch nicht erhalten werden soll (z. B. wenn das Problem durch das Entfernen eines zuvor bereitgestellten Init-Skripts verursacht wurde).

Unterstützung der Portabilität ohne Veränderungen, die die Entwicklung behindern. Debian wird weiterhin als Verbindungsglied zur Integration verschiedener Software betrachtet, die gleichwertige oder ähnliche Funktionalität bietet. Die Portabilität zwischen Hardware-Plattformen und Software-Stacks gehört zu den wichtigen Aufgaben, und die Integration alternativer Technologien wird begrüßt, selbst wenn die Ansichten ihrer Schöpfer vom allgemeinen Konsens abweichen. Die Haltung gegenüber systemd und anderen Init-Systemen entspricht vollständig Punkt 4.

Die Überführung der Unterstützung mehrerer Init-Systeme in die Kategorie der Verpflichtungen. Die Möglichkeit, Debian mit Init-Systemen, die von systemd abweichen, zu starten, bleibt für das Projekt von Bedeutung. Jedes Paket muss mit pid1-Handlern funktionieren, die von systemd abweichen, es sei denn, die im Paket enthaltene Software ist ausschließlich für den Betrieb mit systemd vorgesehen und es besteht kein Support für einen Start ohne systemd (das Fehlen von Init-Skripten wird nicht als ausschließlich für den Betrieb mit systemd vorgesehen angesehen).

Unterstützung von Portabilität und mehreren Implementierungen. Die allgemeinen Prinzipien stimmen vollständig mit Punkt 5 überein, jedoch gibt es keine spezifischen Anforderungen bezüglich systemd und Initialization-Systemen, und es werden keine Verpflichtungen für die Entwickler auferlegt. Den Entwicklern wird nahegelegt, die Interessen der 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 inakzeptabler Optionen zu reduzieren.

Quelle: opennet.ru