Resultaten av omröstningen om Debians init-system har sammanfattats

Publicerad resultat allmän omröstning (GR, allmän upplösning) av Debianprojektutvecklarna som är involverade i paketunderhåll och underhåll av infrastruktur, utfört i frågan om att stödja flera init-system. Den andra posten ("B") i listan vann - systemd förblir att föredra, men möjligheten att behålla alternativa initieringssystem kvarstår. Omröstningen genomfördes med metoden Condorcet, där varje väljare rangordnar alla alternativ i preferensordning, och vid beräkning av resultatet tas hänsyn till hur många väljare som föredrar ett alternativ framför ett annat.

Det vinnande förslaget erkänner att systemd service-enheter är det föredragna sättet att konfigurera demoner och tjänster att köra, men erkänner att det finns miljöer där utvecklare och användare kan skapa och använda alternativa init-system och funktionella alternativ till systemds kapacitet. Utvecklare av alternativa lösningar kräver resurser för att utföra sitt arbete och formatera sina paket. Alternativa lösningar som elogind för att köra applikationer bundna till systemspecifika gränssnitt är fortfarande viktiga för projektet. Stöd till sådana initiativ kräver hjälp inom områden där utveckling av alternativ teknik korsar resten av projektet, som att fördröja lappgranskning och diskussion.

Paket kan innehålla både systemd-enhetsfiler och init-skript för att starta tjänster. Paket kan använda alla systemfunktioner som paketunderhållaren önskar, så länge som funktionerna följer Debians regler och inte är bundna till experimentella eller ostödda Debianfunktioner i andra paket. Förutom systemd kan paketen även innehålla stöd för alternativa init-system och tillhandahålla komponenter för att ersätta systemd-specifika gränssnitt. Beslut om inkludering av patchar fattas av underhållare som en del av standardprocedurer. Debian är engagerad i att arbeta med derivatdistributioner som väljer att använda andra init-system, men interaktionen byggs på underhållarnivå, som fattar beslut om vilka funktioner som förbereds av tredjepartsdistributioner som accepteras i Debians huvudkomposition och vilka som finns kvar i derivatfördelningen.

Låt oss komma ihåg att den tekniska kommittén 2014 godkänd övergång standarddistribution på systemd, men inte tränade beslut om stöd för flera försörjningssystem (punkten som anger kommitténs ovilja att fatta beslut i denna fråga vann omröstningen). Kommittéledaren rekommenderade att paketunderhållarna skulle behålla stödet för sysvinit som ett alternativt init-system, men antydde att han inte kunde påtvinga sin synpunkt och att beslutet borde fattas självständigt i varje enskilt fall.

Efter detta försökte några utvecklare försök att genomföra allmän omröstning, men den preliminära omröstningen visade att det inte fanns något behov av att fatta ett beslut i frågan om att använda flera initieringssystem. För några månader sedan, efter problem med inkluderingen av elogind-paketet (nödvändigt för att köra GNOME utan systemd) i testgrenen på grund av en konflikt med libsystemd, togs frågan åter upp av Debians projektledare, eftersom utvecklarna inte kunde komma överens, och deras kommunikation förvandlades till en konfrontation och nådde en återvändsgränd.

Övervägda alternativ:

Huvudfokus ligger på systemd. Att tillhandahålla stöd för alternativa init-system är inte en prioritet, men underhållare kan valfritt inkludera init-skript för sådana system i paket.

systemd förblir att föredra, men möjligheten att behålla alternativa initieringssystem finns kvar. Teknologier som elogind, som gör att applikationer bundna till systemd kan köras i alternativa miljöer, ses som viktiga. Paket kan innehålla init-filer för alternativa system.

Stöd för en mängd olika init-system och möjligheten att starta upp Debian med andra init-system än systemd.
För att köra tjänster måste paketen innehålla init-skript; att endast tillhandahålla systemd-enhetsfiler utan sysv init-skript är oacceptabelt.

Stöd för system som inte använder systemd, men utan att göra ändringar som skulle hindra utvecklingen. Utvecklarna är överens om att stödja flera init-system under överskådlig framtid, men anser också att det är nödvändigt att arbeta med att förbättra systemstödet. Utvecklingen och underhållet av specifika lösningar bör överlåtas till de samhällen som är intresserade av dessa lösningar, men andra underhållare bör aktivt hjälpa till och bidra till problemlösning när behovet uppstår. Helst bör paket fungera med vilket init-system som helst, vilket kan uppnås genom att tillhandahålla traditionella init-skript eller använda andra mekanismer som gör att de kan arbeta utan systemd. Oförmågan att arbeta utan systemd anses vara en bugg, men inte en utgivningsblockerande bugg, såvida det inte finns en färdig lösning för att arbeta utan systemd, men den vägras att sparas (till exempel när problemet orsakas av borttagning av ett tidigare tillhandahållet init-skript).

Stöder portabilitet utan att införa förändringar som hindrar utvecklingen. Debian fortsätter att ses som en brygga för att integrera olika programvaror som tillhandahåller motsvarande eller liknande funktionalitet. Portabilitet mellan hårdvaruplattformar och mjukvarustackar är ett viktigt mål, och integrationen av alternativa tekniker uppmuntras, även om deras skapares världsbild skiljer sig från den allmänna konsensus. Positionen gällande systemd och andra initieringssystem sammanfaller helt med punkt 4.

Att göra stöd för flera initieringssystem obligatoriskt. Att tillhandahålla möjligheten att köra Debian med andra init-system än systemd fortsätter att vara viktigt för projektet. Varje paket måste fungera med andra pid1-hanterare än systemd, såvida inte programvaran som ingår i paketet ursprungligen var avsedd att fungera endast med systemd och inte stöder körning utan systemd (avsaknaden av init-skript räknas inte som avsedd endast för att arbeta med systemd) .

Stöder portabilitet och flera implementeringar. De allmänna principerna är exakt desamma som punkt 5, men det finns inga specifika krav på systemd- och init-system, och inga skyldigheter åläggs utvecklare. Utvecklare uppmuntras att ta hänsyn till varandras intressen, göra kompromisser och hitta gemensamma lösningar som är tillfredsställande för olika parter.

Fortsatt diskussion. Objektet kan användas för att nedgradera oacceptabla alternativ.

Källa: opennet.ru