La rezultoj de la voĉdono pri Debianaj init-sistemoj estis resumitaj

Eldonita la rezultoj ĝenerala voĉdonado (GR, general resolution) разработчиков проекта Debian, участвующих в сопровождении пакетов и поддержании инфраструктуры, проводившегося по вопросу поддержки нескольких систем инициализации. Победил второй пункт («B») в списке — предпочитаемым остаётся systemd, но оставляется возможность сопровождения альтернативных систем инициализации. Голосование проводилось методом Кондорсе, при котором каждый голосующий ранжирует все варианты в порядке их предпочтения, а при вычислении результата учитывается сколько голосующих предпочитает один вариант другому.

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

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

Ni rememoru, ke en 2014 la teknika komitato aprobita transiro defaŭlta distribuo sur systemd, sed ne ellaboris решения по отношению к поддержке нескольких систем инициализации (при голосовании победил пункт, указывающий на неготовность комитета вынести решение по данному вопросу). Лидер комитета порекомендовал сопровождающим пакеты сохранить поддержку sysvinit в качестве альтернативной системы инициализации, но указал, что не может навязывать свою точку зрения и в каждом случае решение следует принимать самостоятельно.

Post tio, iuj programistoj provis provo efektivigi ĝenerala voĉdono, sed prepara voĉdonado montris, ke ne necesas fari decidon pri la temo de uzado de multoblaj komencaj sistemoj. Antaŭ kelkaj monatoj, post problemoj kun la inkludo de la pako elogind (necesa por ruli GNOME sen systemd) en la testan branĉon pro konflikto kun libsystemd, la problemo denove estis levita de la Debian-projektestro, ĉar la programistoj ne povis konsenti, kaj ilia komunikado fariĝis konfrontiĝo kaj atingis sakstraton.

Рассматривавшиеся варианты:

La ĉefa fokuso estas sur systemd. Provizi subtenon por alternativaj initsistemoj ne estas prioritato, sed prizorgantoj povas laŭvole inkluzivi init-skriptojn por tiaj sistemoj en pakaĵoj.

systemd restas preferita, sed la ebleco konservi alternativajn komencajn sistemojn restas. Teknologioj kiel ekzemple elogind, kiuj permesas al aplikoj ligitaj al systemd funkcii en alternativaj medioj, estas rigardataj kiel gravaj. Pakoj povas inkluzivi init-dosierojn por alternativaj sistemoj.

Subteno por diversaj initsistemoj kaj la kapablo lanĉi Debianon per initsistemoj krom systemd.
Por ruli servojn, pakaĵoj devas inkluzivi init-skriptojn; liverado de nur systemd-unuodosieroj sen sysv-init-skriptoj estas neakceptebla.

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

Subtenas porteblon sen enkonduki ŝanĝojn, kiuj malhelpas la disvolviĝon. Debian daŭre estas vidita kiel ponto por integri malsaman programaron kiu disponigas ekvivalentan aŭ similan funkciecon. Portebleco inter hardvarplatformoj kaj programaro stakoj estas grava celo, kaj la integriĝo de alternativaj teknologioj estas kuraĝigita, eĉ se la mondkoncepto de iliaj kreintoj diferencas de la ĝenerala konsento. La pozicio koncerne systemd kaj aliajn komencajn sistemojn tute koincidas kun punkto 4.

Farante subtenon por multoblaj komencaj sistemoj deviga. Provizi la kapablon ruli Debian per init sistemoj krom systemd daŭre estas grava por la projekto. Ĉiu pakaĵo devas funkcii kun pid1-traktiloj krom systemd, krom se la programaro inkluzivita en la pakaĵo estis origine intencita por funkcii nur kun systemd kaj ne subtenas ruladon sen systemd (la foresto de init-skriptoj ne kalkulas kiel celita nur por labori kun systemd) .

Subtenas porteblon kaj multoblajn efektivigojn. La ĝeneralaj principoj estas ekzakte la samaj kiel punkto 5, sed ne ekzistas specifaj postuloj por systemd kaj init sistemoj, kaj neniuj obligacioj estas truditaj al programistoj. Programistoj estas kuraĝigitaj konsideri reciproke la interesojn, fari kompromisojn kaj trovi komunajn solvojn kontentigajn por diversaj partioj.

Daŭra diskuto. La objekto povas esti uzata por malaltigi neakcepteblajn opciojn.

fonto: opennet.ru