Podsumowano wyniki głosowania nad systemami init Debiana

Opublikowany Ustalenia głosowanie ogólne (GR, uchwała ogólna) twórców projektu Debiana zajmujących się utrzymaniem pakietów i utrzymaniem infrastruktury, prowadzonych w kwestii obsługi systemów wielokrotnych initów. Wygrała druga pozycja („B”) na liście – systemd pozostaje preferowany, ale pozostaje możliwość utrzymania alternatywnych systemów inicjalizacji. Głosowanie odbyło się metodą Condorcet, w którym każdy wyborca ​​szereguje wszystkie opcje w kolejności preferencji, a przy obliczaniu wyniku bierze się pod uwagę, ilu wyborców preferuje jedną opcję od drugiej.

Zwycięska propozycja potwierdza, że ​​jednostki usług systemd są preferowanym sposobem konfigurowania demonów i usług do działania, ale przyznaje, że istnieją środowiska, w których programiści i użytkownicy mogą tworzyć i używać alternatywnych systemów init oraz funkcjonalnych alternatyw dla możliwości systemd. Twórcy alternatywnych rozwiązań potrzebują zasobów do wykonywania swojej pracy i formatowania swoich pakietów. Alternatywne rozwiązania, takie jak elogind, do uruchamiania aplikacji powiązanych z interfejsami specyficznymi dla systemu, pozostają ważne dla projektu. Wspieranie takich inicjatyw wymaga pomocy w obszarach, w których rozwój technologii alternatywnych krzyżuje się z resztą projektu, takich jak opóźnianie przeglądu poprawek i dyskusji.

Pakiety mogą zawierać zarówno pliki jednostek systemowych, jak i skrypty init do uruchamiania usług. Pakiety mogą wykorzystywać dowolne funkcje systemowe, jakie sobie życzy opiekun pakietu, pod warunkiem, że te funkcje są zgodne z zasadami Debiana i nie są powiązane z eksperymentalnymi lub nieobsługiwanymi funkcjami Debiana w innych pakietach. Oprócz systemd pakiety mogą również zawierać obsługę alternatywnych systemów init i udostępniać komponenty zastępujące interfejsy specyficzne dla systemd. Decyzje dotyczące dołączenia poprawek podejmowane są przez opiekunów w ramach standardowych procedur. Debian jest zaangażowany w współpracę z dystrybucjami pochodnymi, które korzystają z innych systemów init, ale interakcja jest budowana na poziomie opiekuna, który podejmuje decyzje o tym, które funkcje przygotowane przez dystrybucje innych firm zostaną przyjęte do głównego składu Debiana, a które pozostawione w dystrybucji instrumentów pochodnych.

Przypomnijmy, że w 2014 roku komitet techniczny zatwierdzony przejście domyślna dystrybucja na systemd, ale nie wyszło decyzje dotyczące wsparcia systemów wielozadaniowych (w głosowaniu zwyciężył punkt wskazujący na niechęć komisji do podjęcia decyzji w tej sprawie). Lider komisji zalecił opiekunom pakietów utrzymanie wsparcia dla sysvinit jako alternatywnego systemu init, ale wskazał, że nie może narzucać swojego punktu widzenia i że decyzja powinna być podejmowana niezależnie w każdym przypadku.

Następnie niektórzy programiści próbowali to zrobić próbować przeprowadzić głosowanie powszechne, ale głosowanie wstępne pokazało, że nie ma potrzeby podejmowania decyzji w kwestii stosowania wielokrotnych systemów inicjalizacji. Kilka miesięcy temu, po problemy wraz z włączeniem pakietu elogind (niezbędnego do uruchomienia GNOME bez systemd) w gałęzi testowej z powodu konfliktu z libsystemd, problem został ponownie podniesiony przez lidera projektu Debian, ponieważ programiści nie mogli dojść do porozumienia, a ich komunikacja zamieniła się w konfrontacji i dotarliśmy do ślepego zaułka.

Rozważane opcje:

Główny nacisk położony jest na systemd. Zapewnienie wsparcia dla alternatywnych systemów init nie jest priorytetem, ale opiekunowie mogą opcjonalnie dołączyć do pakietów skrypty init dla takich systemów.

systemd pozostaje preferowany, ale pozostaje możliwość utrzymania alternatywnych systemów inicjalizacji. Technologie takie jak elogind, które umożliwiają aplikacjom związanym z systemd działanie w alternatywnych środowiskach, są postrzegane jako ważne. Pakiety mogą zawierać pliki inicjujące dla alternatywnych systemów.

Obsługa różnych systemów init i możliwość uruchamiania Debiana z systemami init innymi niż systemd.
Aby uruchomić usługi, pakiety muszą zawierać skrypty init; niedopuszczalne jest dostarczanie wyłącznie plików jednostek systemowych bez skryptów init sysv.

Wsparcie dla systemów, które nie korzystają z systemu, ale bez wprowadzania zmian utrudniających rozwój. Twórcy zgadzają się na obsługę wielu systemów inicjujących w dającej się przewidzieć przyszłości, ale uważają również, że konieczna jest praca nad ulepszeniem obsługi systemowej. Rozwój i utrzymanie konkretnych rozwiązań należy pozostawić społecznościom zainteresowanym tymi rozwiązaniami, ale inni opiekunowie powinni aktywnie pomagać i przyczyniać się do rozwiązywania problemów, gdy zajdzie taka potrzeba. W idealnym przypadku pakiety powinny działać przy użyciu dowolnego systemu init, co można osiągnąć poprzez dostarczenie tradycyjnych skryptów init lub użycie innych mechanizmów, które pozwalają im działać bez systemd. Niemożność pracy bez systemd jest uważana za błąd, ale nie za błąd blokujący wydanie, chyba że istnieje gotowe rozwiązanie do pracy bez systemd, ale nie chce się go zapisać (na przykład, gdy problem jest spowodowany przez usunięcie wcześniej dostarczonego skryptu init).

Obsługuje przenośność bez wprowadzania zmian utrudniających rozwój. Debian nadal jest postrzegany jako pomost umożliwiający integrację różnych programów zapewniających równoważną lub podobną funkcjonalność. Przenośność pomiędzy platformami sprzętowymi i stosami oprogramowania jest ważnym celem i zachęca się do integracji alternatywnych technologii, nawet jeśli światopogląd ich twórców różni się od ogólnego konsensusu. Stanowisko dotyczące systemd i innych systemów inicjalizacji całkowicie pokrywa się z punktem 4.

Wprowadzenie obowiązku obsługi wielu systemów inicjalizacji. Zapewnienie możliwości uruchamiania Debiana z systemami inicjującymi innymi niż systemd jest nadal ważne dla projektu. Każdy pakiet musi współpracować z procedurami obsługi pid1 innymi niż systemd, chyba że oprogramowanie zawarte w pakiecie było pierwotnie przeznaczone do pracy tylko z systemd i nie obsługuje działania bez systemd (brak skryptów init nie liczy się jako przeznaczony tylko do pracy z systemd) .

Obsługuje przenośność i wiele implementacji. Ogólne zasady są dokładnie takie same jak w punkcie 5, ale nie ma konkretnych wymagań dla systemów systemd i init, a na programistów nie są nakładane żadne obowiązki. Zachęcamy deweloperów do uwzględniania wzajemnych interesów, zawierania kompromisów i znajdowania wspólnych rozwiązań, satysfakcjonujących różne strony.

Ciąg dalszy dyskusji. Przedmiotu można użyć do obniżenia niedopuszczalnych opcji.

Źródło: opennet.ru