Debian och Fedora försöker ta itu med beroendeproblemet

Linux-distributioner står inför problemet med ökande beroenden av projekten, dock antalet beroenden för Python-, Perl- och Ruby-koden behålls Inom rimliga gränser övar JavaScript-projekt att delas upp i mycket små bibliotek, ofta med en enkel funktion.

NPM-förvaret har redan över en miljon paket och typiska applikationer länk till hundratals beroenden, som i sin tur har sina egna beroenden, vilket gör det svårt att underhålla och distribuera traditionella paket med JavaScript-applikationer på Linux-distributioner.

På grund av den snäva sammanflätningen av JavaScript-beroendeberoenden, uppdateras alla paket med sådana bibliotek i en distribution det kan bryta andra paket.

Versionsbindningar förvärrar problemet: ett bibliotek kan kräva en version av ett beroende för att fungera stabilt, och ett annat kan kräva en annan.

Många projekt kräver att de senaste versionerna av biblioteken fungerar, som inte alltid uppfyller distributionens stabilitetskrav (kontinuerlig utveckling tillämpas i Node.js-ekosystemet med de senaste versionerna av ramverk och distributionen behöver stöd i flera år).

Försök att fixa paketversioner enbart i distributionen leda till en ökning av föråldrade versioner i arkivet som inte har uppdaterats på flera år. Störning av underhåll för ett paket påverkar många andra paket negativt och skapar ännu fler problem.

Dessutom lkorsberoenden leda till att många bibliotek av Node.js blir omöjligt att avinstallera från systemet, vilket i sin tur förhindrar avinstallation av andra Node.js-program.

För att ta itu med detta godkände Fedora-projektet nyligen en plan för att stoppa standardbildningen av separata paket med bibliotek som används i Node.js-baserade projekt.

Han bestämde sig, från och med Fedora 34, att endast leverera baspaket för Node.js med en tolk, rubriker, primära bibliotek, binärer och grundläggande pakethanteringsverktyg (NPM, garn).

I Fedora-arkivapplikationer som använder Node.js, det är tillåtet att bädda in alla befintliga beroenden i ett paket, utan att dela och separera biblioteken som används i separata paket.

Inbäddning av bibliotek kommer att bli av med små paketrörelser, förenkla paketunderhåll (tidigare spenderade underhållaren mer tid på att granska och testa hundratals paket med bibliotek än i huvudpaketet med programmet), spara infrastruktur från konflikter av bibliotek och lösa problem med länkning till biblioteksversioner (underhållare kommer att inkludera testade och produktionstestade versioner i paketet).

Nackdelen med integrationen kommer att vara komplikationen av korrigeringsprocessen sårbarheter i biblioteken, vilket kräver ett samordnat arbete av underhållarna av alla paket som innehåller det sårbara biblioteket. Det finns en risk att ett paket kommer att glömma att uppdatera ett sårbart inbyggt bibliotek och paketet kommer att bli obemärkt.

Utvecklarna av Debian diskuterar också förändringen till en liknande modell för integrering av beroenden i paket. Förutom Node.js berör diskussionen skapandet av paket för Kubernetes-plattformen och projekt på PHP- och Go-språken, för vilka det finns en tendens att dela upp i små beroenden. Inget beslut har ännu fattats, men man hoppas att problemet med tiden bara kommer att bli värre och förr eller senare kommer projektet att tvingas göra något.

Webbgränssnittet gsa (Greenbone Security Assistant) för säkerhetsskannern gvm (Greenbone Vulnerability Management) nämns som ett exempel på de problem som pakethållare har.

Den Debian-levererade versionen av gsa visade sig vara oförenlig med nyare versioner av gvm, men det var inte möjligt att uppdatera gsa till den aktuella versionen eftersom den innehåller betydande ändringar och använder npm för att ladda ner nödvändiga Node.js-bibliotek.

De begärda biblioteken är för många och kräver att nya paket skapas i Debian för att någon ska kunna underhålla dem, eftersom Debians regler förbjuder att externa komponenter laddas under byggprocessen.

Fuente: https://lwn.net/