Debian en Fedora proberen het afhankelijkheidsprobleem aan te pakken

Linux-distributies hebben te maken met het probleem van toenemende afhankelijkheden van de projecten, hoewel het aantal afhankelijkheden voor Python-, Perl- en Ruby-code blijft behouden Binnen redelijke grenzen oefenen JavaScript-projecten in zeer kleine bibliotheken, vaak met een eenvoudige functie.

De NPM-repository heeft al meer dan een miljoen pakketten en typische toepassingen link naar honderden afhankelijkheden, die op hun beurt hun eigen afhankelijkheden hebben, waardoor het moeilijk is om traditionele pakketten met JavaScript-applicaties op Linux-distributies te onderhouden en te distribueren.

Vanwege de nauwe verwevenheid van JavaScript-bibliotheekafhankelijkheden, moet elk pakket met dergelijke bibliotheken in een distributie worden bijgewerkt het kan andere pakketten breken.

Versiebindingen verergeren het probleem: voor de ene bibliotheek kan de ene versie van een afhankelijkheid stabiel zijn, en voor de andere een andere.

Veel projecten vereisen de nieuwste versies van bibliotheken om te werken, die niet altijd voldoen aan de stabiliteitsvereisten van de distributie (continue ontwikkeling wordt beoefend in het Node.js-ecosysteem met behulp van de nieuwste versies van frameworks, en de distributie heeft ondersteuning nodig gedurende meerdere jaren).

Pogingen om pakketversies alleen in de distributie te repareren leiden tot een toename van verouderde versies in de repository die al jaren niet meer is bijgewerkt. Onderbreking van het onderhoud voor één pakket heeft een nadelig effect op veel andere pakketten en zorgt voor nog meer problemen.

Bovendien londerlinge afhankelijkheden leiden ertoe dat veel bibliotheken van Node.js kan niet meer van het systeem worden verwijderd, wat op zijn beurt voorkomt dat u andere Node.js-programma's verwijdert.

Om met deze situatie om te gaan, keurde het Fedora-project onlangs een plan goed om de standaardformatie van afzonderlijke pakketten met bibliotheken die worden gebruikt in op Node.js gebaseerde projecten te stoppen.

Hij besloot, te beginnen met Fedora 34, om alleen basispakketten voor Node.js te leveren met een interpreter, headers, primaire bibliotheken, binaire bestanden en basispakketbeheertools (NPM, yarn).

In Fedora repository applicaties die Node.js gebruiken, het is toegestaan ​​om alle bestaande afhankelijkheden in een pakket in te bedden, zonder de bibliotheken die in afzonderlijke pakketten worden gebruikt, te verdelen en te scheiden.

Het insluiten van bibliotheken zal een einde maken aan kleine pakketruis, pakketonderhoud vereenvoudigen (voorheen besteedde de onderhouder meer tijd aan het beoordelen en testen van honderden pakketten met bibliotheken dan in het hoofdpakket met het programma), bespaar infrastructuur voor conflicten van bibliotheken en lossen problemen op met het linken naar bibliotheekversies (beheerders zullen geteste en op productie geteste versies in het pakket opnemen).

De keerzijde van integratie is de complicatie van het proces om correcties aan te brengen kwetsbaarheden in de bibliotheken, die een gecoördineerd werk vereisen van de beheerders van alle pakketten die de kwetsbare bibliotheek bevatten. Het gevaar bestaat dat een pakket vergeet een kwetsbare ingebouwde bibliotheek bij te werken en het pakket onopgemerkt blijft.

De ontwikkelaars van Debian bespreekt ook om over te schakelen naar een soortgelijk pakketafhankelijkheidsintegratiemodel. Naast Node.js heeft de discussie betrekking op het maken van pakketten voor het Kubernetes-platform en projecten in de PHP- en Go-talen, waarvoor de neiging bestaat om in kleine afhankelijkheden op te splitsen. Er is nog geen beslissing genomen, maar het is te hopen dat het probleem na verloop van tijd alleen maar erger wordt en dat het project vroeg of laat gedwongen zal worden om iets te doen.

De gsa (Greenbone Security Assistant) webinterface voor de gvm (Greenbone Vulnerability Management) beveiligingsscanner wordt genoemd als een voorbeeld van de problemen die pakketbeheerders hebben.

De door Debian geleverde versie van gsa bleek incompatibel te zijn met nieuwere versies van gvm, maar het was niet mogelijk om gsa bij te werken naar de huidige versie, aangezien het belangrijke wijzigingen bevat en npm gebruikt om de noodzakelijke Node.js-bibliotheken te downloaden.

De gevraagde bibliotheken zijn te veel en vereisen de creatie van nieuwe pakketten in Debian voordat iemand ze kan onderhouden, aangezien de regels van Debian het laden van externe componenten tijdens het bouwproces verbieden.

bron: https://lwn.net/