Підбито підсумки голосування про системи ініціалізації в Debian

Опубліковано результати загального голосування (GR, general resolution) розробників проекту Debian, які беруть участь у супроводі пакетів та підтримці інфраструктури, що проводився з питань підтримки кількох систем ініціалізації. Переміг другий пункт («B») у списку — відданим systemd, але залишається можливість супроводу альтернативних систем ініціалізації. Голосування проводилося методом Кондорсі, у якому кожен голосуючий ранжує всі варіанти порядку їх переваги, а при обчисленні результату враховується скільки голосуючих віддає перевагу один варіант іншому.

Переможний варіант визнає, що сервісні юніти systemd є кращим способом налаштування запуску демонів і сервісів, але допускає, що існують оточення, в яких розробники та користувачі можуть створювати та застосовувати альтернативні системи ініціалізації та функціональні альтернативи можливостям systemd. Розробникам альтернативних рішень потрібно надання ресурсів щодо їх роботи і форматування пакетів. Альтернативні рішення, подібні до elogind, що застосовуються для організації запуску додатків, прив'язаних до інтерфейсів, специфічних для systemd, залишаються важливими для проекту. Підтримка подібних ініціатив вимагає сприяння в областях, в яких альтернативні технології, що розвиваються, перетинаються з рештою проекту, наприклад, неприпустиме затягування рецензування патчів та проведення обговорень.

До пакетів допускається включення як unit-файлів systemd, так і init-скриптів для запуску сервісів. Пакети можуть використовувати будь-які можливості systemd за бажанням супроводжуючого пакету, за умови, що ці можливості відповідають вимогам правил Debian і не прив'язані до експериментальних або непідтримуваних у Debian можливостей інших пакетів. Крім systemd пакети можуть включати підтримку альтернативних систем ініціалізації і надавати компоненти для заміни специфічних інтерфейсів systemd. Рішення щодо включення патчів приймаються супроводжуючими в рамках штатних процедур. Debian зобов'язується працювати з похідними дистрибутивами, які вибрали інші системи ініціалізації, але взаємодія будується на рівні супроводжуючих, на яких лягають рішення про те, які підготовлені сторонніми дистрибутивами можливості приймати в основний склад Debian, а які залишати в похідному дистрибутиві.

Нагадаємо, що у 2014 році технічний комітет затвердила перехід дистрибутива за промовчанням на systemd, але не виробив рішення щодо підтримки кількох систем ініціалізації (при голосуванні переміг пункт, що вказує на неготовність комітету винести рішення з цього питання). Лідер комітету порекомендував супроводжуючим пакетам зберегти підтримку sysvinit як альтернативну систему ініціалізації, але вказав, що не може нав'язувати свою точку зору і в кожному випадку рішення слід приймати самостійно.

Після цього деякими розробниками було вжито спроба проведення загального голосування, але попереднє голосування показало відсутність необхідності ухвалення рішення щодо використання кількох систем ініціалізації. Кілька місяців тому, після проблем з включенням пакету elogind (необхідний для роботи GNOME без systemd) у гілку testing через конфлікт з libsystemd, питання було повторно порушено лідером проекту Debian, оскільки розробники не змогли домовитися, а їхнє спілкування переросло в протистояння і зайшло в глухий кут.

Розглянуті варіанти:

Основна увага фокусується на systemd. Надання підтримки альтернативних систем ініціалізації не є пріоритетом, але ті, хто супроводжує право опціонально включати в пакети init-скрипти для таких систем.

Віддається перевага systemd, але залишається можливість супроводу та альтернативних систем ініціалізації. Технології, такі як elogind, що дозволяють в альтернативних оточеннях запускати програми, прив'язані до systemd, розглядаються як важливі. До пакетів допускається включення init-файлів для альтернативних систем.

Підтримка різноманітних систем ініціалізації та можливість завантаження Debian із системами ініціалізації, відмінними від systemd.
Для запуску сервісів пакети обов'язково повинні включати init-скрипти, постачання лише unit-файлів systemd без sysv init-скриптів неприпустиме.

Підтримка систем, що не використовують systemd, але без внесення змін, що заважають розвитку. Розробники погоджуються підтримувати кілька систем ініціалізації в найближчому майбутньому, але також вважають за необхідне працювати над поліпшенням підтримки systemd. Розробкою та супроводом специфічних рішень слід займатися зацікавленим у таких рішеннях співтовариствам, але інші мейнтейнери повинні активно допомагати та сприяти вирішенню проблем, коли в цьому виникає потреба. В ідеалі пакети повинні функціонувати при використанні будь-якої системи ініціалізації, для чого можна постачати традиційні init-скрипти або використовувати інші механізми, що дозволяють працювати без systemd. Неможливість роботи без systemd розглядається як помилка, але не як помилка, що блокує реліз, за ​​винятком випадків, коли є готове рішення для роботи без systemd, але його відмовляються зберігати (наприклад, коли проблема викликана видаленням init-скрипту, що раніше поставлявся).

Підтримка переносимості, без внесення змін, що заважають розвитку. Debian продовжує розглядатися як зв'язуюча ланка для інтеграції різних програм, що надають еквівалентну або схожу функціональність. Переносність між апаратними платформами і програмними стеками належить до важливих завдань, а інтеграція альтернативних технологій вітається, навіть якщо світогляд їхніх творців розходяться із загальним мнением. Позиція щодо systemd та інших систем ініціалізації повністю збігається із 4 пунктом.

Переведення підтримки кількох систем ініціалізації до розряду обов'язкових. Надання можливості запуску Debian із системами ініціалізації, відмінними від systemd, продовжує мати значення для проекту. Кожен пакет повинен працювати з обробниками pid1, відмінними від systemd, крім випадків, коли що входить у пакет ПЗ спочатку призначено до роботи лише з systemd і відсутня підтримка запуску без systemd (відсутність init-скриптів вважається призначенням лише роботи з systemd).

Підтримка переносимості та кількох реалізацій. Загальні принципи повністю збігаються з пунктом 5, але щодо systemd і систем ініціалізації не пред'являються конкретні вимоги, а також не накладаються будь-які зобов'язання на розробників. Розробникам пропонується враховувати інтереси один одного, йти на компроміси та знаходити спільні рішення, задовільні для різних сторін.

Продовження обговорення. Пункт може бути використаний для зниження рейтингу неприйнятних варіантів.

Джерело: opennet.ru