Sam Hartman, Debians prosjektleder, å forstå uenighetene knyttet til leveringen av elogind-pakken som en del av distribusjonen. I juli er teamet ansvarlig for å forberede utgivelser inkludering av elogind i testgrenen, siden denne pakken er i konflikt med libsystemd.
Husker at gir grensesnittene som trengs for å kjøre GNOME uten å installere systemd. Prosjektet ble grunnlagt som en gaffel av systemd-logind, plassert i en egen pakke og frigjort fra binding til systemd-komponenter. Elogind leverer blant annet sin egen versjon av libelogind-biblioteket, som tar på seg en rekke funksjoner som tilbys i libsystemd og erstatter dette biblioteket under installasjonen.
Årsakene til blokkeringen var en konflikt med systemd-pakken og faren for å erstatte libsystemd med et alternativt libelogind, som er fullstendig uforenlig med kildebiblioteket på ABI-nivå.
Pakkeetikettene elogind er i konflikt med systemd-biblioteker, men det er iboende designet for å fungere bare uten systemd, og konflikt med systemd er faktisk fordelaktig fordi det forhindrer elogind fra å bli installert ved en feiltakelse. På den annen side, i sin nåværende form, resulterer forsøk via APT på å oppdatere konfigurasjonen fra systemd til versjonen med sysvinit og elogind med APT som ikke fungerer. Men selv om denne mangelen er eliminert, forblir overgangen fra systemd til elogind umulig uten å slette allerede installerte brukermiljøer.
De eloginde utviklerne var tilpasse elogind til å fungere på toppen av standard libpam-systemd, uten å bruke sitt eget libpam-elogind-lag. Overgangen av elogind til libpam-systemd hemmes av mangelen på støtte for konseptet med skiver, men utviklerne av elogind ønsker ikke å oppnå full samsvar med API og nøyaktig gjenta alle funksjonene til systemd, siden elogind bare gir minimalt funksjonalitet for å organisere brukerpålogginger og tar ikke sikte på å replikere alle systemd undersystemer.
Løsning av de beskrevne tekniske problemene bør løses på nivået av samhandling mellom utgivelsesteamet og elogind og systemd vedlikeholderne, men prosjektlederen ble tvunget til å gripe inn fordi teamene ikke kunne bli enige, felles arbeid utviklet seg til konfrontasjon og løsningen på problemet nådde en blindvei, der hver side hadde rett på sin egen måte. I følge Sam Hartman nærmer situasjonen seg en stat som krever en generell avstemning (GR, generell resolusjon), der fellesskapet skal bestemme alternative systemer for init og støtte for sysvinit med elogind.
Hvis prosjektmedlemmer stemmer for å diversifisere init-systemer, vil alle vedlikeholdere være involvert i å jobbe sammen for å løse dette problemet, eller spesifikke utviklere vil bli tildelt å jobbe med dette problemet, og vedlikeholdere vil ikke lenger kunne ignorere et alternativt init-system, være stille, eller forsinke prosessen.
Foreløpig allerede i depotet 1033-pakker som gir serviceenheter for systemd, men som ikke inkluderer init.d-skript. For å løse dette problemet leverer servicefiler som standard, men klargjør en behandler som automatisk vil analysere kommandoer fra disse filene og generere init.d-skript basert på dem.
Hvis fellesskapet bestemmer at Debian har nok støtte for et enkelt init-system, kan vi ikke lenger bekymre oss for sysvinit og elogind og kun fokusere på enhetsfiler og systemd. Denne avgjørelsen vil negativt påvirke porter som ikke bruker Linux-kjernen (, и ), men det er ingen slike porter i hovedarkivet ennå, og de har ikke statusen .
Binding til systemd vil også gjøre det mye vanskeligere å endre retningen på distribusjonen i fremtiden og vil begrense videre eksperimentering innen initialisering og service management. Å opprettholde elogind i arbeidsform er mye enklere enn å slette den og deretter prøve å legge den til igjen. Hvert beslutningsalternativ har fordeler og ulemper, så en fullstendig diskusjon av alle fordeler og ulemper vil være nødvendig før avstemning.
Kilde: opennet.ru