Debians init systems afstemning er blevet opsummeret

Udgivet resultaterne almindelig afstemning (GR, generel opløsning) Debian-projektudviklere involveret i pakkevedligeholdelse og infrastrukturvedligeholdelse, udført på spørgsmålet om at understøtte flere init-systemer. Det andet punkt ("B") på listen vandt - systemd forbliver det foretrukne, men muligheden for at opretholde alternative init-systemer forbliver. Afstemningen blev foretaget af Condorcet, hvor hver vælger rangerer alle muligheder i rækkefølge efter deres præference, og ved beregningen af ​​resultatet tages der højde for, hvor mange vælgere, der foretrækker en mulighed frem for en anden.

Det vindende bidrag anerkender, at systemd service units er den foretrukne måde at konfigurere dæmon og service opstart på, men tillader, at der er miljøer, hvor udviklere og brugere kan oprette og bruge alternative init-systemer og funktionelle alternativer til systemds muligheder. Udviklere af alternative løsninger kræver, at der stilles ressourcer til rådighed for at udføre deres arbejde og formatere pakker. Alternative løsninger som elogind til lancering af applikationer bundet til systemd-specifikke grænseflader er fortsat vigtige for projektet. Støtte til sådanne initiativer kræver bistand på områder, hvor alternative teknologier, der udvikles, overlapper med resten af ​​projektet, såsom at forsinke patch-gennemgange og diskussioner.

Pakker kan indeholde både systemd-enhedsfiler og init-scripts til at starte tjenester. Pakker kan bruge alle funktioner i systemd som ønsket af vedligeholderen af ​​pakken, så længe disse funktioner overholder kravene i Debian-reglerne og ikke er bundet til funktioner, der er eksperimentelle eller forældede i Debian fra andre pakker. Ud over systemd kan pakker også omfatte understøttelse af alternative init-systemer og levere komponenter til at erstatte systemd-specifikke grænseflader. Beslutninger om medtagelse af plastre træffes af vedligeholdere som en del af de almindelige procedurer. Debian er forpligtet til at arbejde med afledte distributioner, der vælger forskellige init-systemer, men interaktionen er på niveauet af vedligeholdere, som træffer beslutninger om, hvilke tredjepartsfunktioner der er inkluderet i Debians hoveddistribution, og hvilke der er tilbage i den afledte distribution .

Husk på, at det tekniske udvalg i 2014 godkendt overgang standarddistribution på systemd, men ikke fungerede beslutninger vedrørende støtte til flere init-systemer (et punkt vundet ved afstemningen, hvilket indikerer, at udvalget ikke var klar til at træffe en beslutning om dette spørgsmål). Udvalgslederen anbefalede, at pakkevedligeholdere bibeholdt støtten til sysvinit som et alternativt init-system, men indikerede, at han ikke kunne påtvinge sit synspunkt, og i hvert enkelt tilfælde skulle beslutningen træffes uafhængigt.

Efter det har nogle udviklere taget et forsøg på almindelig afstemning, men den foreløbige afstemning viste, at der ikke var behov for at tage stilling til brugen af ​​flere initialiseringssystemer. For et par måneder siden, efter problemer med inkluderingen af ​​elogind-pakken (kræves for at køre GNOME uden systemd) i testgrenen på grund af en konflikt med libsystemd, blev problemet rejst igen af ​​Debians projektleder, da udviklerne ikke kunne blive enige, og deres kommunikation voksede til en konfrontation og nåede en blindgyde.

Overvejede muligheder:

Hovedfokus er på systemd. At yde support til alternative init-systemer er ikke en prioritet, men vedligeholdere kan frit pakke init-scripts til sådanne systemer.

Systemd er fortsat det foretrukne valg, men opretholder også alternative init-systemer. Teknologier såsom elogind, der tillader alternative miljøer at køre systembundne applikationer, ses som vigtige. Pakker kan indeholde init-filer til alternative systemer.

Understøttelse af en række init-systemer og muligheden for at starte Debian med andre init-systemer end systemd.
For at starte tjenester skal pakker indeholde init-scripts, levering af kun systemd-enhedsfiler uden sysv init-scripts er uacceptabelt.

Support til systemer, der ikke bruger systemd, men uden at lave ændringer, der forstyrrer udviklingen. Udviklerne er enige om at understøtte flere init-systemer i en overskuelig fremtid, men føler også behovet for at arbejde på at forbedre systemunderstøttelse. Udvikling og vedligeholdelse af specifikke løsninger bør overlades til de samfund, der er interesserede i sådanne løsninger, men andre vedligeholdere bør aktivt hjælpe og bidrage til at løse problemer, når behovet opstår. Ideelt set bør pakker fungere ved hjælp af ethvert init-system, som kan forsynes med traditionelle init-scripts eller andre mekanismer, der gør det muligt at arbejde uden systemd. Manglende evne til at arbejde uden systemd betragtes som en fejl, men ikke en udgivelsesblokerende fejl, medmindre der er en klar løsning til at arbejde uden systemd, men nægter at beholde den (f.eks. når problemet er forårsaget af fjernelse af et tidligere afsendt init-script).

Støtte til portabilitet, uden at lave ændringer, der hindrer udvikling. Debian bliver fortsat set som en bro til integration af forskellig software, der giver tilsvarende eller lignende funktionalitet. Portabilitet mellem hardwareplatforme og softwarestakke er vigtigt, og integrationen af ​​alternative teknologier er velkommen, selvom deres skaberes verdensbillede afviger fra den generelle opfattelse. Stillingen vedrørende systemd og andre init-systemer er nøjagtig den samme som punkt 4.

Gør support til flere init-systemer obligatorisk. At tillade Debian at køre med andre init-systemer end systemd er fortsat vigtigt for projektet. Hver pakke skal fungere med ikke-systemd pid1-handlere, medmindre den pakkede software oprindeligt er designet til kun at fungere med systemd, og der ikke er understøttelse for at køre uden systemd (manglende init-scripts anses ikke for at være systemd-only).

Understøttelse af portabilitet og flere implementeringer. De generelle principper er de samme som punkt 5, men der er ingen specifikke krav til systemd- og init-systemer, og der pålægges ingen forpligtelser for udviklere. Udviklere opfordres til at tage hensyn til hinandens interesser, indgå kompromiser og finde fælles løsninger, der er tilfredsstillende for forskellige parter.

Fortsættelse af diskussionen. Varen kan bruges til at sænke vurderingen af ​​uacceptable muligheder.

Kilde: opennet.ru