Sam Hartman, Debians projektledare, att förstå de meningsskiljaktigheter som är förknippade med leveransen av elogind-paketet som en del av distributionen. I juli ansvarar teamet för att förbereda releaser inkludering av elogind i testgrenen, eftersom detta paket är i konflikt med libsystemd.
Minns att tillhandahåller de gränssnitt som behövs för att köra GNOME utan att installera systemd. Projektet grundades som en gaffel av systemd-logind, placerad i ett separat paket och befriad från bindning till systemd-komponenter. Elogind tillhandahåller bland annat en egen version av biblioteket libelogind, som tar på sig ett antal funktioner som erbjuds i libsystemd och ersätter detta bibliotek under installationen.
Anledningarna till blockeringen var en konflikt med systemd-paketet och faran med att ersätta libsystemd med ett alternativt libelogind, vilket är helt inkompatibelt med källbiblioteket på ABI-nivå.
Paketetiketterna elogind är i konflikt med systemd-bibliotek, men det är i sin natur utformat för att fungera endast utan systemd, och konflikt med systemd är faktiskt fördelaktigt eftersom det förhindrar elogind från att installeras av misstag. Å andra sidan, i sin nuvarande form, leder försök via APT att uppdatera konfigurationen från systemd till versionen med sysvinit och elogind. med APT som inte fungerar. Men även om denna brist elimineras, förblir övergången från systemd till elogind omöjlig utan att ta bort redan installerade användarmiljöer.
De eloginda utvecklarna var anpassa elogind för att fungera ovanpå standard libpam-systemd, utan att använda sitt eget libpam-elogind-lager. Övergången av elogind till libpam-systemd hämmas av bristen på stöd för konceptet skivor, men utvecklarna av elogind vill inte uppnå full överensstämmelse med API:n och exakt upprepa alla funktioner i systemd, eftersom elogind bara ger minimal funktionalitet för att organisera användarinloggningar och syftar inte till att replikera alla systemd undersystem.
Lösning av de beskrivna tekniska problemen bör lösas på nivån av interaktion mellan releaseteamet och elogind och systemd underhållare, men projektledaren tvingades ingripa eftersom teamen inte kunde komma överens, gemensamt arbete utvecklades till konfrontation och lösningen på problemet nådde en återvändsgränd, där varje sida hade rätt på sitt sätt. Enligt Sam Hartman närmar sig situationen en stat som kräver en allmän omröstning (GR, allmän resolution), där samhället ska besluta om alternativa system för init och stöd för sysvinit med elogind.
Om projektmedlemmar röstar för att diversifiera init-system kommer alla underhållare att vara involverade i att arbeta tillsammans för att lösa detta problem eller så kommer specifika utvecklare att tilldelas att arbeta med det här problemet och underhållare kommer inte längre att kunna ignorera ett alternativt init-system, vara tysta, eller fördröja processen.
Finns redan i förvaret för närvarande 1033-paket som tillhandahåller serviceenheter för systemd, men som inte inkluderar init.d-skript. För att lösa det här problemet tillhandahålla servicefiler som standard, men förbered en hanterare som automatiskt skulle analysera kommandon från dessa filer och generera init.d-skript baserat på dem.
Om communityn beslutar att Debian har tillräckligt med stöd för ett enda init-system, kan vi inte längre oroa oss för sysvinit och elogind och bara fokusera på enhetsfiler och systemd. Detta beslut kommer att negativt påverka portar som inte använder Linux-kärnan (, и ), men det finns inga sådana portar i huvudarkivet ännu och de har inte statusen .
Bindning till systemd kommer också att göra det mycket svårare att ändra riktningen på distributionen i framtiden och kommer att begränsa ytterligare experimenterande inom området initiering och servicehantering. Att behålla elogind i fungerande form är mycket lättare än att ta bort det och sedan försöka lägga till det igen. Varje beslutsalternativ har för- och nackdelar, så en fullständig diskussion av alla för- och nackdelar kommer att krävas innan man röstar.
Källa: opennet.ru