Sam Hartman, Debiana Projektestro, kompreni la malkonsentojn asociitajn kun la livero de la eloginda pako kiel parto de la distribuo. En julio, la teamo respondecas pri preparado de ĵetoj inkludo de elogind en la testa branĉo, ĉar ĉi tiu pako konfliktas kun libsystemd.
Memoru tion provizas la interfacojn necesajn por ruli GNOME sen instali systemd. La projekto estis fondita kiel forko de systemd-logind, metita en apartan pakaĵon kaj liberigita de ligado al systemd-komponentoj. Interalie, elogind disponigas sian propran version de la biblioteko libelogind, kiu prenas kelkajn funkciojn ofertitajn en libsystemd kaj anstataŭigas ĉi tiun bibliotekon dum instalado.
La kialoj de blokado estis konflikto kun la systemd-pakaĵo kaj la danĝero de anstataŭigi libsystemd kun alternativa libelogind, kiu estas tute malkongrua kun la fontbiblioteko ĉe la ABI-nivelo.
La pakaĵo etikedas elogind kiel konfliktanta kun systemd-bibliotekoj, sed ĝi estas esence desegnita por funkcii nur sen systemd, kaj konflikti kun systemd estas fakte utila ĉar ĝi malhelpas ke elogind estu instalita erare. Aliflanke, en ĝia nuna formo, provoj per APT ĝisdatigi la agordon de systemd al la versio kun sysvinit kaj elogind rezultigas kun APT ne funkcianta. Sed eĉ se ĉi tiu manko estas forigita, la transiro de systemd al elogind restas neebla sen forigo de jam instalitaj uzantmedioj.
La elogindaj programistoj estis adapti elogind por labori super norma libpam-systemd, sen uzi sian propran libpam-elogind tavolo. La transiro de elogind al libpam-systemd estas malhelpita de la manko de subteno por la koncepto de tranĉaĵoj, sed la programistoj de elogind ne volas atingi plenan konformecon kun la API kaj ekzakte ripeti ĉiujn kapablojn de systemd, ĉar elogind nur provizas minimuman. funkcieco por organizi uzantajn ensalutojn kaj ne celas reprodukti ĉiujn systemd-subsistemojn.
Solvo de la priskribitaj teknikaj problemoj devus esti solvita je la nivelo de interagado inter la eldona teamo kaj la elogindaj kaj systemd-subtenantoj, sed la projektestro estis devigita interveni ĉar la teamoj ne povis konsenti, komuna laboro disvolviĝis al konfrontiĝo kaj la solvo al la problemo atingis sakstraton, en kiu ĉiu flanko pravis laŭ sia maniero. Laŭ Sam Hartman, la situacio alproksimiĝas al ŝtato postulanta ĝeneralan voĉdonon (GR, ĝenerala rezolucio), en kiu la komunumo decidos pri alternativaj sistemoj por init kaj subteno por sysvinit kun elogind.
Se projektmembroj voĉdonas por diversigi initsistemojn, ĉiuj prizorgantoj partoprenos kunlabori por solvi ĉi tiun problemon aŭ specifaj programistoj estos asignitaj por labori pri ĉi tiu afero kaj prizorgantoj ne plu povos ignori alternativan initsistemon, resti silentaj, aŭ prokrasti la procezon.
Nuntempe jam en la deponejo 1033 pakaĵoj kiuj provizas servounuojn por systemd, sed ne inkluzivas init.d-skriptojn. Por solvi ĉi tiun problemon liveru servodosierojn defaŭlte, sed preparu pritraktilon kiu aŭtomate analizus komandojn de ĉi tiuj dosieroj kaj generus init.d-skriptojn bazitajn sur ili.
Se la komunumo decidas, ke Debian havas sufiĉe da subteno por ununura initsistemo, ni ne plu povas zorgi pri sysvinit kaj elogind kaj koncentriĝi nur pri unuodosieroj kaj systemd. Ĉi tiu decido influos negative pordojn kiuj ne uzas la Linuksan kernon (, и ), sed tiaj havenoj ankoraŭ ne estas en la ĉefa arkivo kaj ili ne havas la statuson .
Ligado al systemd ankaŭ faros multe pli malfacila ŝanĝi la direkton de la distribuo estonte kaj limigos plian eksperimentadon en la kampo de inicialigo kaj administrado de servo. Konservi elogind en funkcianta formo estas multe pli facila ol forigi ĝin kaj poste provi aldoni ĝin denove. Ĉiu decida opcio havas avantaĝojn kaj malavantaĝojn, do plena diskuto pri ĉiuj avantaĝoj kaj malavantaĝoj estos postulata antaŭ voĉdoni.
fonto: opennet.ru