Resultatene av avstemningen om Debians init-systemer er oppsummert

Publisert funn generell avstemning (GR, generell oppløsning) av Debian-prosjektutviklerne involvert i pakkevedlikehold og infrastrukturvedlikehold, utført på spørsmålet om å støtte flere init-systemer. Det andre elementet (“B”) i listen vant - systemd forblir foretrukket, men muligheten for å opprettholde alternative initialiseringssystemer gjenstår. Stemmegivningen ble gjennomført etter metoden Condorcet, der hver velger rangerer alle alternativer i preferanserekkefølge, og ved beregning av resultatet tas det hensyn til hvor mange velgere som foretrekker ett alternativ fremfor et annet.

Vinnerforslaget erkjenner at systembaserte tjenesteenheter er den foretrukne måten å konfigurere demoner og tjenester til å kjøre, men erkjenner at det finnes miljøer der utviklere og brukere kan lage og bruke alternative init-systemer og funksjonelle alternativer til systemds muligheter. Utviklere av alternative løsninger krever ressurser for å utføre arbeidet sitt og formatere pakkene sine. Alternative løsninger som elogind for å kjøre applikasjoner bundet til systemd-spesifikke grensesnitt er fortsatt viktige for prosjektet. Å støtte slike initiativ krever bistand på områder der utvikling av alternative teknologier krysser hverandre med resten av prosjektet, for eksempel å utsette gjennomgang og diskusjon av oppdateringer.

Pakker kan inneholde både systemd-enhetsfiler og init-skript for å starte tjenester. Pakker kan bruke alle systemfunksjoner pakkevedlikeholderen ønsker, så lenge funksjonene er i samsvar med Debian-reglene og ikke er knyttet til eksperimentelle eller ikke-støttede Debian-funksjoner i andre pakker. I tillegg til systemd, kan pakker også inkludere støtte for alternative init-systemer og gi komponenter for å erstatte systemd-spesifikke grensesnitt. Avgjørelser angående inkludering av patcher tas av vedlikeholdere som en del av standardprosedyrer. Debian er forpliktet til å jobbe med avledede distribusjoner som velger å bruke andre init-systemer, men interaksjonen bygges på vedlikeholdsnivå, som tar beslutninger om hvilke funksjoner utarbeidet av tredjepartsdistribusjoner som aksepteres i Debians hovedsammensetning og hvilke som er igjen i derivatfordelingen.

La oss huske at i 2014 den tekniske komiteen godkjent overgang standarddistribusjon på systemd, men ikke utarbeidet beslutninger angående støtte for flere provisjonssystemer (punktet som indikerer komiteens manglende vilje til å ta en beslutning om dette spørsmålet vant avstemningen). Utvalgslederen anbefalte at pakkevedlikeholdere opprettholder støtten til sysvinit som et alternativt init-system, men antydet at han ikke kunne påtvinge sitt synspunkt og at avgjørelsen bør tas uavhengig i hvert enkelt tilfelle.

Etter dette forsøkte noen utviklere forsøke å gjennomføre generell avstemning, men foreløpig avstemning viste at det ikke var behov for å ta en beslutning om spørsmålet om bruk av flere initialiseringssystemer. For noen måneder siden, etter problemer med inkluderingen av elogind-pakken (nødvendig for å kjøre GNOME uten systemd) i testgrenen på grunn av en konflikt med libsystemd, ble problemet igjen tatt opp av Debians prosjektleder, siden utviklerne ikke kunne bli enige, og kommunikasjonen deres ble til en konfrontasjon og kom til en blindvei.

Alternativer som vurderes:

Hovedfokus er på systemd. Å gi støtte for alternative init-systemer er ikke en prioritet, men vedlikeholdere kan eventuelt inkludere init-skript for slike systemer i pakker.

systemd forblir foretrukket, men muligheten for å opprettholde alternative initialiseringssystemer er igjen. Teknologier som elogind, som lar applikasjoner bundet til systemd kjøre i alternative miljøer, blir sett på som viktige. Pakker kan inneholde init-filer for alternative systemer.

Støtte for en rekke init-systemer og muligheten til å starte Debian med andre init-systemer enn systemd.
For å kjøre tjenester, må pakker inkludere init-skript å levere bare systemd-enhetsfiler uten sysv init-skript er uakseptabelt.

Støtte for systemer som ikke bruker systemd, men uten å gjøre endringer som hindrer utviklingen. Utviklerne er enige om å støtte flere init-systemer i overskuelig fremtid, men mener også det er nødvendig å jobbe med å forbedre systemstøtten. Utvikling og vedlikehold av spesifikke løsninger bør overlates til lokalsamfunnene som er interessert i disse løsningene, men andre vedlikeholdere bør aktivt hjelpe og bidra til problemløsning når behovet oppstår. Ideelt sett bør pakker fungere ved å bruke et hvilket som helst init-system, som kan oppnås ved å levere tradisjonelle init-skript eller bruke andre mekanismer som lar dem fungere uten systemd. Manglende evne til å arbeide uten systemd anses som en feil, men ikke en utgivelsesblokkerende feil, med mindre det finnes en ferdig løsning for å jobbe uten systemd, men den nektes å bli lagret (for eksempel når problemet er forårsaket av fjerning av et tidligere levert init-skript).

Støtter portabilitet uten å innføre endringer som hindrer utvikling. Debian fortsetter å bli sett på som en bro for integrering av annen programvare som gir tilsvarende eller lignende funksjonalitet. Portabilitet mellom maskinvareplattformer og programvarestabler er et viktig mål, og integrasjon av alternative teknologier oppmuntres, selv om verdensbildet til skaperne deres skiller seg fra den generelle konsensus. Stillingen angående systemd og andre initialiseringssystemer er fullstendig sammenfallende med punkt 4.

Gjør støtte for flere initialiseringssystemer obligatorisk. Å tilby muligheten til å kjøre Debian med andre init-systemer enn systemd, fortsetter å være viktig for prosjektet. Hver pakke må fungere med andre pid1-behandlere enn systemd, med mindre programvaren som er inkludert i pakken, opprinnelig var ment å fungere bare med systemd og ikke støtter kjøring uten systemd (fraværet av init-skript teller ikke som kun beregnet for arbeid med systemd) .

Støtter portabilitet og flere implementeringer. De generelle prinsippene er nøyaktig de samme som pkt. 5, men det er ingen spesifikke krav til systemd og init-systemer, og det pålegges ingen forpliktelser for utviklere. Utviklere oppfordres til å ta hensyn til hverandres interesser, inngå kompromisser og finne felles løsninger som er tilfredsstillende for ulike parter.

Fortsatt diskusjon. Elementet kan brukes til å nedgradere uakseptable alternativer.

Kilde: opennet.ru