Debian zal opnieuw meerdere initialisatiesystemen ondersteunen

debian10

Sam Hartmann, de Debian-projectleider, geprobeerd om meningsverschillen over de levering van het elogind-pakket op te lossen als onderdeel van de distributie. In juli, het team dat verantwoordelijk is voor het voorbereiden van de lanceringen blokkeerde de opname van elogind in de testtak, aangezien dit pakket in strijd is met libsystemd.

Als reden voor een crash was er een conflict met het systemd-pakket en het gevaar om libsystemd te vervangen met een alternatieve versie van libelogind, die volledig incompatibel is met de bronbibliotheek op ABI-niveau.

Op elogind is het belangrijk om te weten dat het de nodige interfaces biedt zodat Gnome kan werken zonder systemd te installeren. Het project is gebaseerd als een tak van systemd-logind, uitgepakt in een apart pakket en opgeslagen vanuit de link naar de systemd componenten.

De opname van elogind biedt een eigen versie van de libelogind-bibliotheek, die een aantal functies overneemt die door libsystemd worden aangeboden en deze bibliotheek tijdens de installatie vervangt.

In het pakket wordt elogind gemarkeerd als conflicterend met de systemd-bibliotheken, maar het is inherent ontworpen om alleen te werken zonder systemd en een conflict met systemd is zelfs gunstig omdat het u niet toestaat om per ongeluk elogind te installeren.

Aan de andere kant, in de huidige vorm, pogingen via APT om de systemd-configuratie bij te werken naar versie met sysvinit en elogind resulteert in een beschadigd systeem met een niet-werkende APT. Maar zelfs met het verwijderen van deze fout is de overgang van systemd naar elogind nog steeds onmogelijk zonder reeds geïnstalleerde gebruikersomgevingen te verwijderen.

Waarop Elogind-ontwikkelaars werd gevraagd om lofrede aan te passend om bovenop het gewone libpam-systemd te werken, zonder zijn eigen libpam-elogind-laag te gebruiken.

De overgang van elogind naar libpam-systemd wordt bemoeilijkt door een gebrek aan ondersteuning voor het concept van sectoren, maar de ontwikkelaars van elogind willen geen volledige API-conformiteit bereiken en precies alle functies van systemd herhalen, aangezien elogind slechts minimale functionaliteit biedt om te organiseren gebruikerslogins en het wordt niet voorgesteld om alle subsystemen van systemd te herhalen.

Het oplossen van de geschetste technische problemen moet worden opgelost op het niveau van de interactie tussen het releaseteam en de beheerders van elogind en systemd, maar de projectleider moest ingrijpen omdat de teams het niet eens konden worden, het gezamenlijke werk werd een confrontatie en de oplossing voor het probleem liep dood, waarbij elke kant van de wet op zijn eigen manier.

Volgens Sam Hartman, de situatie nadert een staat die een algemene stemming vereist (GR, algemene resolutie), waarin de gemeenschap zal beslissen over alternatieve systemen om sysvinit met elogind te initialiseren en te ondersteunen.

Als projectdeelnemers stemmen om initialisatiesystemen te diversifiëren, alle degenen die verantwoordelijk zijn voor het onderhoud zullen deelnemen aan een gezamenlijke inspanning om dit probleem op te lossen of speciale verantwoordelijke ontwikkelaars zullen worden aangesteld om aan deze kwestie te werken en degenen die hen vergezellen zullen niet langer in staat zijn om het alternatieve initialisatiesysteem te omzeilen, te zwijgen of het proces te vertragen.

Momenteel heeft de repository al 1033 pakketten verzameld die service-eenheden leveren voor systemd, maar die geen init.d-scripts bevatten.

Om dit probleem op te lossen, wordt voorgesteld om standaard servicebestanden aan te leveren, maar om een ​​stuurprogramma voor te bereiden dat automatisch de commando's in deze bestanden parseert en op basis daarvan init.d-scripts genereert.

Als de gemeenschap besluit dat Debian voldoende ondersteuning heeft voor een enkel initialisatiesysteem, hoeven ze zich geen zorgen meer te maken over sysvinit en elogind, en richten ze zich alleen op unit- en systeembestanden.

Een dergelijke oplossing heeft een negatief effect op poorten die de Linux-kernel niet gebruiken, maar er zijn nog geen dergelijke poorten in het hoofdbestand en ze hebben geen officiële ondersteuningsstatus.

Koppelen aan systemd zal de verandering ook aanzienlijk bemoeilijken in de richting van distributieontwikkeling in de toekomst en zal verdere experimenten op het gebied van service-initialisatie en -beheer beperken.

Elke oplossing heeft zijn voor- en nadelen, dus een grondige bespreking van alle argumenten voor en tegen zal voorafgaand aan de stemming vereist zijn.

bron: https://lists.debian.org/


Laat je reactie achter

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *

*

*

  1. Verantwoordelijk voor de gegevens: AB Internet Networks 2008 SL
  2. Doel van de gegevens: Controle SPAM, commentaarbeheer.
  3. Legitimatie: uw toestemming
  4. Mededeling van de gegevens: De gegevens worden niet aan derden meegedeeld, behalve op grond van wettelijke verplichting.
  5. Gegevensopslag: database gehost door Occentus Networks (EU)
  6. Rechten: u kunt uw gegevens op elk moment beperken, herstellen en verwijderen.

  1.   Handboek zei

    Het is dus nog steeds niet zeker of ze sysvinit weer zullen ondersteunen !! Zoals ik het heb begrepen, gaan ze het voorleggen aan een studie en aan een stemming! We zullen zien wat er gebeurt!!

    1.    geweldig zei

      Nee

  2.   01101001b zei

    Het Debian circus "pronkte" al met de lachwekkende "beslissing" om systemd over te nemen. Nu gaan ze niet terugdeinzen, dus die mogelijke "algemene stemming" is al aangekondigd. Voor mij, blijf rouleren met systemd. Q gaat uiteindelijk worden opgehangen, is ook een ander gezongen resultaat.