Samas Hartmanas, „Debian“ projekto vadovas, suprasti nesutarimus, susijusius su „elogind“ paketo pristatymu, kaip paskirstymo dalimi. Liepos mėnesį komanda, atsakinga už leidimų rengimą elogind įtraukimas į testavimo šaką, nes šis paketas prieštarauja libsystemd.
Prisimink tai suteikia sąsajas, reikalingas GNOME paleidimui neįdiegus systemd. Projektas buvo įkurtas kaip systemd-logind šakutė, įdėtas į atskirą paketą ir atlaisvintas nuo susiejimo su systemd komponentais. Be kita ko, elogind pateikia savo libelogind bibliotekos versiją, kuri įgauna daugybę libsystemd siūlomų funkcijų ir pakeičia šią biblioteką diegimo metu.
Blokavimo priežastys buvo konfliktas su paketu systemd ir pavojus, kad libsystemd bus pakeistas alternatyviu libelogind, kuris yra visiškai nesuderinamas su šaltinio biblioteka ABI lygiu.
Paketų etiketės elogind prieštarauja systemd bibliotekoms, tačiau iš esmės yra sukurtos veikti tik be systemd, o konfliktas su systemd iš tikrųjų yra naudingas, nes neleidžia per klaidą įdiegti elogind. Kita vertus, dabartinės formos bandymai per APT atnaujinti konfigūraciją iš systemd į versiją su sysvinit ir elogind kai APT neveikia. Tačiau net ir pašalinus šį trūkumą, perėjimas nuo systemd prie elogind išlieka neįmanomas nepanaikinus jau įdiegtų vartotojų aplinkų.
Elogindo kūrėjai buvo pritaikyti elogind dirbti su standartine libpam-systemd, nenaudodama savo libpam-elogind sluoksnio. Elogind perėjimą prie libpam-systemd trukdo slice koncepcijos palaikymo trūkumas, tačiau elogind kūrėjai nenori pasiekti visiško API atitikimo ir tiksliai pakartoti visas systemd galimybes, nes elogind suteikia tik minimalų. funkcionalumą, skirtą vartotojų prisijungimams organizuoti, ir nesiekia atkartoti visų sisteminių posistemių.
Aprašytų techninių problemų sprendimas turėtų būti sprendžiamas sąveikos tarp išleidimo komandos ir elogind bei sistemos prižiūrėtojų lygmeniu, tačiau projekto vadovas buvo priverstas įsikišti, nes komandos negalėjo susitarti, bendras darbas peraugo į konfrontaciją ir problemos sprendimą. problema pateko į aklavietę, kurioje kiekviena pusė buvo savaip teisi. Pasak Samo Hartmano, situacija artėja prie būsenos, reikalaujančios bendros rezoliucijos (GR), kurioje bendruomenė nuspręs dėl alternatyvių init ir sysvinit palaikymo sistemų su elogind.
Jei projekto nariai nubalsuos už init sistemų įvairinimą, visi prižiūrėtojai bus įtraukti į bendrą darbą sprendžiant šią problemą arba konkretiems kūrėjams bus pavesta dirbti su šia problema ir prižiūrėtojai nebegalės ignoruoti alternatyvios init sistemos, tylėti arba atidėti procesą.
Šiuo metu jau yra saugykloje 1033 paketai, teikiantys „systemd“ paslaugų vienetus, bet neapima init.d scenarijų. Norėdami išspręsti šią problemą pagal numatytuosius nustatymus teikti paslaugų failus, bet paruošti tvarkyklę, kuri automatiškai analizuotų komandas iš šių failų ir pagal jas generuotų init.d scenarijus.
Jei bendruomenė nuspręs, kad Debian'as turi pakankamai palaikymo vienai init sistemai, mes nebegalime jaudintis dėl sysvinit ir elogind ir susitelkti tik į vienetinius failus ir systemd. Šis sprendimas neigiamai paveiks prievadus, kurie nenaudoja Linux branduolio (, и ), tačiau pagrindiniame archyve tokių prievadų dar nėra ir jie neturi statuso .
Prisijungimas prie systemd taip pat apsunkins platinimo krypties keitimą ateityje ir apribos tolesnius eksperimentus inicijavimo ir paslaugų valdymo srityje. Išlaikyti elogindą darbinėje formoje yra daug lengviau, nei jį ištrinti ir vėl bandyti pridėti. Kiekvienas sprendimo variantas turi privalumų ir trūkumų, todėl prieš balsuojant reikės išsamiai aptarti visus už ir prieš.
Šaltinis: opennet.ru