Es hat eine allgemeine Abstimmung über die Initialisierungssysteme in Debian begonnen.
Debian-Projekt zum Start (GR, allgemeine Resolution) der Entwickler des Projekts bezüglich , welches die zukünftige Politik des Projekts hinsichtlich der Bindung an systemd, die Unterstützung alternativer Init-Systeme und die Interaktion mit abgeleiteten Distributionen, die systemd nicht verwenden, bestimmen wird. Die Abstimmung läuft bis einschließlich 27. Dezember, die Ergebnisse werden am 28. Dezember bekannt gegeben.
Erinnern wir uns, dass im Jahr 2014 der technische Ausschuss der Standarddistribution zu systemd, jedoch nicht Entscheidungen bezüglich der Unterstützung mehrerer Init-Systeme (bei der Abstimmung gewann der Punkt, der auf die Unfähigkeit des Komitees hinwies, eine Entscheidung zu diesem Thema zu treffen). Der Vorsitzende des Komitees empfahl den Paketbetreuern, die Unterstützung von sysvinit als alternatives Init-System aufrechtzuerhalten, stellte jedoch klar, dass er seine Meinung nicht auferlegen kann und in jedem Fall die Entscheidung selbst getroffen werden muss.
Daraufhin unternahmen einige Entwickler 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 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 derzeit durchgeführte Abstimmung wird die Politik bezüglich mehrerer Init-Systeme festlegen, und falls der Punkt gewinnt, der die Unterstützung alternativ Init-Systemen vorschreibt, können die Maintainer solche Fragen nicht ignorieren oder hinauszögern. Nach der Diskussion der drei ursprünglich vom Projektleiter vorgeschlagenen Abstimmungspunkte wurde die Anzahl der Optionen auf acht erweitert. Bei der Abstimmung ist die Auswahl mehrerer Punkte mit einer Rangfolge der gewählten Elemente nach Präferenz erlaubt. Etwa tausend Entwickler, die an der Paketpflege und der Infrastruktur arbeiten, haben Stimmrecht.
Vorgeschlagene 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.
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.
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 von Systemen, die systemd nicht verwenden, jedoch ohne Änderungen, die die Entwicklung behindern. Die Entwickler sind bereit, mehrere Init-Systeme in naher Zukunft zu unterstützen, halten es aber auch für notwendig, an der Verbesserung der Unterstützung von systemd zu arbeiten. 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 notwendig wird. Idealerweise sollten Pakete bei Verwendung eines beliebigen Init-Systems funktionieren, weshalb traditionelle Init-Skripte bereitgestellt oder andere Mechanismen verwendet werden können, die eine Funktion ohne systemd ermöglichen. Die Unfähigkeit, ohne systemd zu arbeiten, wird als Fehler angesehen, aber nicht als Fehler, der die Veröffentlichung blockiert, es sei denn, es gibt eine fertige Lösung, um ohne systemd zu arbeiten, die jedoch nicht aufrechterhalten wird (zum Beispiel, 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.
Erwerben Sie zuverlässiges Hosting für Websites mit DDoS-Schutz, VPS VDS-Server🔥 Kaufen Sie zuverlässiges Hosting für Websites mit DDoS-Schutz, VPS VDS-Server | ProHoster