Podsumowanie głosowania na temat systemów inicjalizacji w Debianie

Opublikowano wyniki ogólnych głosowań (GR, ogólna rezolucja) deweloperów projektu Debian, uczestniczących w utrzymaniu pakietów i wspieraniu infrastruktury, odbywającego się w sprawie wsparcia dla kilku systemów inicjalizacji. Zwyciężył drugi punkt („B”) na liście — preferowany pozostaje systemd, ale pozostaje możliwość wspierania alternatywnych systemów inicjalizacji. Głosowanie przeprowadzono metodą Kondorsee, w której każdy głosujący szeregował wszystkie warianty według ich preferencji, a przy obliczaniu wyników uwzględniano, ile osób głosujących preferuje jeden wariant od drugiego.

Zwycięski wariant uznaje, że jednostki serwisowe systemd są preferowanym sposobem konfigurowania uruchamiania demonów i usług, ale dopuszcza, że istnieją środowiska, w których deweloperzy i użytkownicy mogą tworzyć i stosować alternatywne systemy inicjalizacji i funkcjonalne alternatywy dla możliwości systemd. Deweloperzy alternatywnych rozwiązań potrzebują zapewnienia zasobów do prowadzenia swojej pracy i formatowania pakietów. Alternatywne rozwiązania, takie jak elogind, stosowane do organizowania uruchamiania aplikacji związanych z interfejsami specyficznymi dla systemd, pozostają ważne dla projektu. Wsparcie takich inicjatyw wymaga współpracy w obszarach, w których rozwijane alternatywne technologie pokrywają się z resztą projektu, na przykład niedopuszczalne jest opóźnianie recenzji poprawek i prowadzenia dyskusji.

Do paczek można włączyć zarówno pliki jednostkowe systemu systemd, jak i skrypty init do uruchamiania usług. Paczki mogą korzystać z wszelkich możliwości systemu systemd według uznania opiekuna pakietu, pod warunkiem że te możliwości spełniają wymagania zasad Debian i nie są związane z eksperymentalnymi lub nieobsługiwanymi w Debian możliwością z innych pakietów. Oprócz systemd, paczki mogą również zawierać wsparcie dla alternatywnych systemów inicjalizacji oraz dostarczać komponenty do zastąpienia specyficznych interfejsów systemd. Decyzje o włączeniu łatek podejmowane są przez opiekunów w ramach standardowych procedur. Debian zobowiązuje się do współpracy z pochodnymi dystrybucjami, które wybrały dla siebie inne systemy inicjalizacji, lecz współpraca opiera się na poziomie opiekunów, którzy podejmują decyzje dotyczące tego, jakie możliwości przygotowane przez zewnętrzne dystrybucje powinny zostać przyjęte do głównej wersji Debiana, a które powinny pozostać w pochodnej dystrybucji.

Przypomnijmy, że w 2014 roku techniczny komitet zatwierdził przejście domyślnej dystrybucji na systemd, ale nie wypracował decyzji w sprawie wsparcia dla kilku systemów inicjalizacji (w głosowaniu zwyciężył punkt wskazujący na brak gotowości komitetu do podjęcia decyzji w tej kwestii). Lider komitetu zasugerował opiekunom pakietów, aby zachowali wsparcie dla sysvinit jako alternatywnego systemu inicjalizacji, wskazując jednak, że nie może narzucać swojego zdania i że w każdym przypadku należy podejmować decyzję samodzielnie.

Po tym niektórzy programiści podjęli próbę przeprowadzenia ogólnego głosowania, ale wstępne głosowanie wykazało brak potrzeby podjęcia decyzji w sprawie używania kilku systemów inicjalizacji. Kilka miesięcy temu, po problemach z włączeniem pakietu elogind (niezbędnego do działania GNOME bez systemd) do gałęzi testing z powodu konfliktu z libsystemd, temat został ponownie poruszony przez lidera projektu Debian, ponieważ programiści nie mogli dojść do porozumienia, a ich komunikacja przerodziła się w konfrontację i utknęła w martwym punkcie.

Rozważane opcje:

Główna uwaga koncentruje się na systemd. Udzielanie wsparcia dla alternatywnych systemów inicjalizacji nie jest priorytetem, ale towarzyszący mogą opcjonalnie włączać do pakietów skrypty init dla takich systemów.

Preferowanym pozostaje systemd, ale zostawia się możliwość wsparcia i alternatywnych systemów inicjalizacji. Technologie, takie jak elogind, pozwalające w alternatywnych środowiskach uruchamiać aplikacje związane z systemd, są traktowane jako ważne. Do pakietów dopuszcza się włączenie plików init dla alternatywnych systemów.

Wsparcie różnorodnych systemów inicjalizacji oraz możliwość uruchamiania Debian z systemami inicjalizacji innymi niż systemd.
Dla uruchamiania serwisów pakiety muszą obowiązkowo zawierać skrypty init, dostarczanie tylko plików jednostek systemd bez skryptów sysv init jest niedopuszczalne.

Wsparcie dla systemów, które nie używają systemd, ale bez wprowadzania zmian, które mogłyby przeszkadzać w rozwoju. Programiści zgadzają się na wsparcie kilku systemów inicjalizacji w bliskiej przyszłości, ale również uznają za konieczne pracować nad poprawą wsparcia dla systemd. Rozwój i wsparcie specyficznych rozwiązań powinny być realizowane przez zainteresowane takimi rozwiązaniami społeczności, ale inni utrzymujący powinni aktywnie pomagać i wspierać rozwiązywanie problemów, gdy zajdzie taka potrzeba. W idealnym przypadku pakiety powinny działać przy użyciu dowolnego systemu inicjalizacji, do czego można dostarczyć tradycyjne skrypty init lub zastosować inne mechanizmy pozwalające na działanie bez systemd. Niemożność działania bez systemd traktuje się jako błąd, ale nie jako błąd blokujący wydanie, z wyjątkiem przypadków, gdy istnieje gotowe rozwiązanie do pracy bez systemd, ale odmówi się jego zachowania (na przykład, gdy problem jest spowodowany usunięciem wcześniej dostarczanego skryptu init).

Wsparcie przenośności bez wprowadzania zmian, które utrudniają rozwój. Debian wciąż jest postrzegany jako ogniwo łączące różne oprogramowanie, które oferuje równoważną lub podobną funkcjonalność. Przenośność między platformami sprzętowymi a stosami oprogramowania jest jednym z ważnych zadań, a integracja alternatywnych technologii jest mile widziana, nawet jeśli światopogląd ich twórców różni się od ogólnej opinii. Stanowisko w sprawie systemd i innych systemów inicjalizacji w pełni pokrywa się z punktem 4.

Przeniesienie wsparcia dla kilku systemów inicjalizacji do kategorii obowiązkowych. Umożliwienie uruchomienia Debiana z systemami inicjalizacji innymi niż systemd ma nadal znaczenie dla projektu. Każdy pakiet musi działać z obsługą pid1 inną niż systemd, z wyjątkiem przypadków, gdy oprogramowanie wchodzące w skład pakietu zostało pierwotnie zaprojektowane do pracy tylko z systemd i brak jest wsparcia dla uruchomienia bez systemd (brak skryptów init nie jest uznawany za przeznaczenie tylko do pracy z systemd).

Wsparcie przenośności i kilku realizacji. Ogólne zasady w pełni pokrywają się z punktem 5, ale w odniesieniu do systemd i systemów inicjalizacji nie stawiane są konkretne wymagania, ani też nie nakłada się żadnych zobowiązań na deweloperów. Deweloperzy są zachęcani do uwzględniania interesów innych, do kompromisów oraz poszukiwania wspólnych rozwiązań satysfakcjonujących różne strony.

Kontynuacja dyskusji. Punkt ten może być wykorzystywany do obniżania oceny nieakceptowalnych opcji.

Źródło: opennet.ru