Проект Debian объявил 關於開始 全體投票 (GR, general resolution) разработчиков проекта по 支援多個 init 系統的問題, которое определит дальнейшую политику проекта в отношении привязки к systemd, поддержки альтернативных систем инициализации и взаимодействия с производными дистрибутивами, не использующими systemd. Голосование продлится до 27 декабря включительно, итоги будут подведены 28 декабря.
讓我們回顧一下2014年技術委員會 得到正式認可的過渡 systemd 上的預設分發,但不是 解決了 решения по отношению к поддержке нескольких систем инициализации (при голосование победил пункт, указывающий на неготовность комитета вынести решение по данному вопросу). Лидер комитета порекомендовал сопровождающим пакеты сохранить поддержку sysvinit в качестве альтернативной системы инициализации, но указал, что не может навязывать свою точку зрения и в каждом случае решение следует принимать самостоятельно.
Проводимое ныне голосование позволит утвердить политику в отношении нескольких систем инициализации, и если победит пункт, обязывающий поддерживать альтернативные системы, мэйнтейнеры не смогут игнорировать или затягивать подобные вопросы. После обсуждения трёх изначально предложенных лидером проекта пунктов голосования, число вариантов было расширено до восьми. При голосовании допускается выбор сразу нескольких пунктов c ранжированием выбранных элементов по уровню предпочтения. Право голоса имеют около тысячи разработчиков, участвующих в сопровождении пакетов и поддержании инфраструктуры.
Поддержка систем, не использующих systemd, но без внесения изменений, мешающих развитию. Разработчики соглашаются поддерживать несколько систем инициализации в обозримом будущем, но также считают необходимым работать над улучшением поддержки systemd. Разработкой и сопровождением специфичных решений следует заниматься заинтересованным в таких решениях сообществам, но другие мэйнтейнеры должны активно помогать и способствовать решению проблем, когда в этом возникает необходимость. В идеале пакеты должны функционировать при использовании любой системы инициализации, для чего можно поставлять традиционные init-скрипты или использовать иные механизмы, позволяющие работать без systemd. Невозможность работы без systemd рассматривается как ошибка, но не как ошибка блокирующая релиз, за исключением случаев, когда имеется готовое решение для работы без systemd, но его отказываются сохранять (например, когда проблема вызвана удалением ранее поставлявшегося init-скрипта).