Sam Hartman, Debians projektleder, at forstå de uenigheder, der er forbundet med leveringen af elogind-pakken som en del af distributionen. I juli er det team, der er ansvarligt for at forberede udgivelser inklusion af elogind i testgrenen, da denne pakke er i konflikt med libsystemd.
Husk på, at giver de nødvendige grænseflader til at køre GNOME uden at installere systemd. Projektet blev grundlagt som en gaffel af systemd-logind, placeret i en separat pakke og frigjort for binding til systemd-komponenter. Elogind leverer blandt andet sin egen version af libelogind-biblioteket, som påtager sig en række funktioner, der tilbydes i libsystemd og erstatter dette bibliotek under installationen.
Årsagerne til blokeringen var en konflikt med systemd-pakken og faren for at erstatte libsystemd med et alternativt libelogind, som er fuldstændig inkompatibelt med det originale bibliotek på ABI-niveau.
Pakkeetiketterne elogind er i konflikt med systemd-biblioteker, men det er i sagens natur designet til kun at fungere uden systemd, og konflikt med systemd er faktisk fordelagtigt, fordi det forhindrer elogind i at blive installeret ved en fejl. På den anden side, i sin nuværende form, resulterer forsøg via APT på at opdatere konfigurationen fra systemd til versionen med sysvinit og elogind med APT virker ikke. Men selvom denne mangel elimineres, forbliver overgangen fra systemd til elogind umulig uden at slette allerede installerede brugermiljøer.
De eloginde udviklere var tilpasse elogind til at arbejde oven på standard libpam-systemd, uden at bruge sit eget libpam-elogind lag. Overgangen af elogind til libpam-systemd er hæmmet af manglen på støtte til konceptet med skiver, men udviklerne af elogind ønsker ikke at opnå fuld overensstemmelse med API'en og nøjagtigt gentage alle systemd's muligheder, da elogind kun giver minimalt funktionalitet til at organisere brugerlogins og har ikke til formål at replikere alle systemd undersystemer.
Løsning af de beskrevne tekniske problemer skulle løses på niveauet af interaktion mellem release-teamet og elogind og systemd vedligeholdere, men projektlederen var tvunget til at gribe ind, fordi teamene ikke kunne blive enige, fælles arbejde udviklede sig til konfrontation og løsningen på problemet nåede en blindgyde, hvor hver side havde ret på sin egen måde. Ifølge Sam Hartman nærmer situationen sig en stat, der kræver en generel afstemning (GR, generel resolution), hvor samfundet vil tage stilling til alternative systemer til init og støtte til sysvinit med elogind.
Hvis projektmedlemmer stemmer for at diversificere init-systemer, vil alle vedligeholdere være involveret i at arbejde sammen for at løse dette problem, eller specifikke udviklere vil blive tildelt til at arbejde med dette problem, og vedligeholdere vil ikke længere være i stand til at ignorere et alternativt init-system, forblive tavse, eller forsinke processen.
Lige nu allerede i depotet 1033-pakker, der leverer serviceenheder til systemd, men som ikke inkluderer init.d-scripts. For at løse dette problem leverer servicefiler som standard, men klargør en handler, der automatisk vil parse kommandoer fra disse filer og generere init.d-scripts baseret på dem.
Hvis fællesskabet beslutter, at Debian har tilstrækkelig understøttelse til et enkelt init-system, kan vi ikke længere bekymre os om sysvinit og elogind og kun fokusere på enhedsfiler og systemd. Denne beslutning vil negativt påvirke porte, der ikke bruger Linux-kernen (, и ), men der er endnu ingen sådanne porte i hovedarkivet, og de har ikke status .
Binding til systemd vil også gøre det meget sværere at ændre retningen på distributionen i fremtiden og vil begrænse yderligere eksperimenter inden for initialisering og service management. At vedligeholde elogind i arbejdsform er meget nemmere end at slette det og derefter prøve at tilføje det igen. Hver beslutningsmulighed har fordele og ulemper, så en fuldstændig diskussion af alle fordele og ulemper vil være påkrævet før afstemning.
Kilde: opennet.ru