Debian se rozhodl pro systemd, zůstane ale otevřený alternativám

Projekt Debian ukončil hlasování o svém přístupu k init systémům. O jeho nutnosti rozhodl vedoucí projektu Sam Hartman v říjnu letošního roku. Reagoval tak na přibývající problémy s povinnou podporou více init systémů a narůstající komplexitu při tvorbě nových balíčků. Hlasování začalo 7. prosince a skončilo 27. prosince.

Zvítězila volba B: Systemd but we support exploring alternatives. Debian tím vyjádřil svůj postoj k init systémům, který je shrnut v následujícím textu:

Projekt Debian uznává, že service units ze systemd jsou upřednostňovaným způsobem konfigurace startu démonů/služeb. Přesto Debian zůstává prostředím, ve kterém vývojáři a uživatelé mohou zkoumat a vyvíjet alternativní init systémy a náhrady za vlastnosti systemd.

Lidem zajímajícím se o průzkum těchto alternativ musí být poskytnuty nástroje potřebné pro vývoj a balíčkování. Technologie jako elogind, které usnadňují průzkum alternativ pro běh software závisejícím na některém rozhraní systemd, zůstávají pro Debian důležitými. Je zásadní, že projekt podporuje podobné snahy vývojářů, pokud dochází k překryvu těchto technologií se zbytkem projektu. Například přezkoumáváním záplat a svou účastí na diskusích.

Balíčky by měly obsahovat service units nebo init skripty, aby umožnily start démonů a služeb. Balíčky mohou využívat libovolných vlastností systemd dle uvážení jejich správce, pokud je to v souladu s dalšími pravidly a běžnými očekáváními. Balíček by neměl záviset na experimentálních či v Debianu nepodporovaných vlastnostech jiných balíčků. Balíčky mohou obsahovat podporu pro alternativní init systémy vedle systemd a mohou nabízet alternativy pro jakékoliv rozhraní systemd, které využívají. Správci balíčků budou k rozhodování o zařazení záplat používat běžné procedury.

Debian se zavazuje ke spolupráci s deriváty, které provádějí vlastní rozhodnutí ohledně init systémů. Stejně jako při naší veškeré spolupráci s downstreamy, budou příslušní správci rozhodovat o tom, které změny se zavedou do Debianu a které zůstanou čistě v samotném derivátu.

Celkem osm možností

Připomeňme, že vývojáři Debianu měli při hlasování celkem osm různých variant:

• Zaměřit se na systemd
• Systemd s možností průzkumu alternativ (vítězná volba) 
• Podpora více různých init systémů je důležitá
• Podporovat ne-systemd systémy, ale neblokovat pokrok
• Podporovat portovatelnost, ale neblokovat pokrok
• Podpora pro různé init systémy je vyžadována
• Podporovat portovatelnost a různé implementace
• Další diskuse

Všechny zvažované možnosti včetně dlouhého popisu jsou součástí vyhlášení hlasování. Připomeňme, že Debian v podobných případech hlasuje pomocí nástroje Devotee a ke sčítání hlasů používá Condorcetovu metodu.

Proč to bylo potřeba?

Debian se s různými problémy ohledně nejasné politiky týkající se init systémů potýká vlastně od samého počátku, kdy zhruba před pěti lety vyšel Debian Jessie. To byla první verze, která přinesla systemd jako výchozí init systém.

Už v době jeho vývoje se ale ukázalo, že je potřeba se k věci nějak konkrétně postavit. V roce 2014 tedy proběhlo první hlasování, ovšem s velmi nejednoznačným výsledkem – totiž že žádné obecné rozhodnutí není potřeba. Jak se dalo čekat, problémy nezmizely.

Správci balíčků stále nevěděli, jak se v některých případech zachovat. Zejména se to dělo v případě, kdy dorazil balíček se záplatami týkajícími se jiného init systému než systemd. Jak velký důraz je třeba klást na funkčnost pod jiným initem? Musíme vynucovat init skripty, když běžíme na systemd a sysvinit používá jedno procento uživatelů?

Protože neexistovala jednoznačná politika, docházelo čím dál častěji k mezním situacím, na které neexistovalo jasné pravidlo. Situace se navíc postupně zhoršovala s tím, jak vývojáři jednotlivých nástrojů opouštějí podporu jiných init systémů a soustředí se na systemd. Mají tedy správci balíčků trvat na doplnění dalších skriptů? Je to blokující pro zařazení balíčku do Debianu? Dodnes k tomu neexistovalo jednoznačné rozhodnutí a správci postupovali různě.

Poslední kapka jménem elogind

Hlavním spouštěčem hlasování byly pravděpodobně problémy s balíčkem elogind, které Sam Hartman popisoval v srpnovém zpravodaji. Potíže začaly už v červenci, kdy byl jedním z členů release týmu zablokován přestup balíčku do testingu. Démon elogind extrahuje podstatné funkce ze systemd-logind, přičemž sám nakonec nezávisí na systemd jako takovém. Jím poskytované funkce jsou důležité pro moderní desktopová prostředí (KDE/Wayland a GNOME), která je využívají.

Výsledkem je alternativní implementace libsystemd0 a systemd. Pokud je nějaká aplikace slinkovaná s těmito knihovnami, při běhu může bez problémů použít alternativní implementaci z projektu elogind a zachovat tak funkčnost i bez systemd. Více informací získáte na projektovém gitu nebo na Gentoo Wiki.

Pokud se chtějí vývojáři distribuce vyhnout složitým úpravám v každém balíčku, který má kromě systemd podporovat i jiné init systémy, musí takovou alternativní implementaci některých funkcí poskytovat. Dělají to tak i mnohé další distribuce a je to prověřené a funkční řešení.

V Debianu je ovšem s tímto balíčkem spojena ještě další komplexnost, neboť využívá mechanismů dependencies, conflicts, replaces a provides, které dovolují nahradit balíky ze systemd právě popsanými alternativami. Tento mechanismus byl několikrát přepracován, aby dovolil plynulý a automatizovaný přechod od systemd k elogind. Jenže kvůli chybě v utilitě apt nebylo možné tento přechod v nainstalovaném systému uskutečnit, pokud by se během toho neodinstalovalo desktopové prostředí závisející na původních balících se systemd.

Spolupráce mezi různými vývojáři

Tohle je sice technický problém, ale vyžaduje to spolupráci mezi různými vývojářskými týmy: správcem balíku elogind, správcem systemd a členy release týmu. Tady ovšem vznikly potíže, protože ti správní lidé se nebyli schopni dohodnout na jednom funkčním řešení. Výsledkem byla dlouhá a emotivní diskuse prokládaná dlouhými pauzami a dokazující neschopnost se dohodnout. Do role mediátora se pak vložil i Sam Hartman, který chtěl čistě technický problém jednoduše vyřešit.

Uznává, že je to velmi složitý problém, který nemá jednoduché řešení. Chápe ovšem obě strany: jak správci systemd, tak i lidi, kteří se snaží pokračovat v podpoře jiných init systémů. Ovšem jako projekt se Debian musel posunout dál a jeho šéf viděl jedinou možnost ve vyvolání hlasování a vytvoření nového rozhodnutí.

K tomu právě došlo a mělo by to zklidnit emoce uvnitř projektu a ukázat všem vývojářům jasný směr. Bude to znamenat odklon od init skriptů a možnost soustředit se na jeden systém. Je to sice nepříjemné vůči nelinuxovým portům Debianu, ale žádný takový v současné době v oficiálním vydání není.

Zároveň ale současné rozhodnutí neznamená úplný konec alternativních init systémů. Pokud to někomu bude stát za to, může se na jejich podpoře podílet. Projekt Devuan dokazuje, že to za to některým lidem stojí. Debian novým rozhodnutím deklaroval, že nebude takovým aktivitám bránit a naopak je v rozumné míře podpoří.