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

Eldonita la rezultoj ĝenerala voĉdonado (GR, ĝenerala rezolucio) de la Debian-projektaj programistoj implikitaj en pakaĵa prizorgado kaj infrastruktura prizorgado, efektivigita pri la temo de subtenado de multoblaj initsistemoj. La dua ero ("B") en la listo gajnis - systemd restas preferita, sed la ebleco konservi alternativajn komencajn sistemojn restas. Voĉdonado estis farita per la metodo Condorcet, en kiu ĉiu balotanto vicigas ĉiujn elektojn laŭ ordo de prefero, kaj kiam oni kalkulas la rezulton, oni konsideras kiom da balotantoj preferas unu opcion al alia.

La venka propono agnoskas ke systemd-servunuoj estas la preferata maniero agordi demonojn kaj servojn por funkcii, sed agnoskas ke ekzistas medioj en kiuj programistoj kaj uzantoj povas krei kaj uzi alternativajn initsistemojn kaj funkciajn alternativojn al la kapabloj de systemd. Programistoj de alternativaj solvoj postulas rimedojn por plenumi sian laboron kaj formi siajn pakaĵojn. Alternativaj solvoj kiel elogind por ruli aplikojn ligitajn al systemd-specifaj interfacoj restas gravaj por la projekto. Apogi tiajn iniciatojn postulas asistadon en lokoj kie evoluigado de alternativaj teknologioj intersekcas kun la resto de la projekto, kiel ekzemple prokrasti pececan revizion kaj diskuton.

Pakoj povas inkluzivi ambaŭ systemd-unuajn dosierojn kaj init-skriptojn por lanĉi servojn. Pakoj povas uzi iujn ajn systemd-funkciojn, kiujn la pakaĵa prizorganto deziras, kondiĉe ke la funkcioj konformas al Debianaj reguloj kaj ne estas ligitaj al eksperimentaj aŭ nesubtenataj Debian-funkcioj en aliaj pakaĵoj. Aldone al systemd, pakaĵoj ankaŭ povas inkludi subtenon por alternativaj initsistemoj kaj disponigi komponentojn por anstataŭigi systemd-specifajn interfacojn. Decidoj koncerne la inkludon de pecetoj estas faritaj fare de prizorgantoj kiel parto de normaj proceduroj. Debian kompromitas labori kun derivitaj distribuoj, kiuj elektas uzi aliajn initsistemojn, sed la interagado estas konstruita je la prizorganto-nivelo, kiu faras decidojn pri kiuj funkcioj preparitaj per triaj distribuoj estas akceptitaj en la ĉefa Debian-konsisto kaj kiuj estas lasitaj. en la deriva distribuo.

Ni rememoru, ke en 2014 la teknika komitato aprobita transiro defaŭlta distribuo sur systemd, sed ne ellaboris decidoj koncerne subtenon por multoblaj provizsistemoj (la objekto indikanta la malvolon de la komisiono fari decidon pri tiu temo gajnis la voĉdonon). La komitatestro rekomendis, ke pakaĵistoj konservu subtenon por sysvinit kiel alternativa init-sistemo, sed indikis ke li ne povis trudi sian vidpunkton kaj ke la decido estu farita sendepende en ĉiu kazo.

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.

Opcioj konsiderataj:

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.

Subteno por sistemoj kiuj ne uzas systemd, sed sen fari ŝanĝojn kiuj malhelpus la disvolviĝon. La programistoj konsentas subteni plurajn initajn sistemojn por la antaŭvidebla estonteco, sed ankaŭ opinias, ke necesas labori pri plibonigo de sistema subteno. La evoluo kaj prizorgado de specifaj solvoj estu lasitaj al la komunumoj interesitaj pri tiuj solvoj, sed aliaj prizorgantoj devas aktive helpi kaj kontribui al problemo solvado kiam la bezono ekestas. Ideale, pakaĵoj devus funkcii uzante ajnan initsistemon, kiu povas esti atingita liverante tradiciajn init-skriptojn aŭ uzante aliajn mekanismojn kiuj permesas al ili funkcii sen systemd. La malkapablo labori sen systemd estas konsiderata cimo, sed ne liberig-bloka cimo, krom se ekzistas preta solvo por labori sen systemd, sed ĝi estas rifuzita konservi (ekzemple, kiam la problemo estas kaŭzita de la forigo de antaŭe provizita init-skripto).

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