Linuxi distributsioonid seisavad silmitsi sõltuvuste suurenemise probleemiga projektidest, ehkki säilitatakse Pythoni, Perli ja Ruby koodi sõltuvuste arv Mõistlikes piirides harjutavad JavaScripti projektid jagunemist väga väikesteks raamatukogudeks, täites sageli lihtsat funktsiooni.
NPM-i hoidlas on juba üle miljoni paketi ja tüüpilised rakendused link sadadele sõltuvustele, millel on omakorda oma sõltuvus, mis muudab JavaScripti rakendustega traditsiooniliste pakettide hooldamise ja levitamise Linuxi distributsioonides keeruliseks.
JavaScripti teekide sõltuvuste tiheda põimumise tõttu värskendage jaotises selliste pakettide pakette see võib teisi pakette lõhkuda.
Versioonide sidumine süvendab probleemi: ühe teegi jaoks võib olla vajalik, et üks sõltuvuse versioon töötaks stabiilselt, ja teine võib vajada teist.
Paljud projektid nõuavad töötamiseks raamatukogude uusimaid versioone, mis ei vasta alati levitamise stabiilsusnõuetele (Node.js ökosüsteemis harjutatakse pidevat arendamist, kasutades raamistike uusimaid versioone, ja levitamine vajab mitu aastat tuge).
Katsed parandada paketiversioone ainult jaotuses viia vananenud versioonide suurenemiseni hoidlas, mida pole aastaid uuendatud. Ühe paketi hoolduse katkestamine mõjutab negatiivselt paljusid teisi pakette ja tekitab veelgi rohkem probleeme.
Lisaks lristisõltuvused toovad kaasa asjaolu, et paljud Node.js on võimatu süsteemist desinstallida, mis omakorda takistab teiste Node.js programmide desinstallimist.
Selle lahendamiseks kiitis Fedora projekt hiljuti heaks kava peatada Node.js-põhistes projektides kasutatavate teekidega eraldi pakettide vaikimisi moodustamine.
Alustades Fedora 34-st, otsustas ta tarnida Node.js-le ainult tõlke, päiste, esmaste teekide, binaarkaartide ja põhipakettide haldamise tööriistade (NPM, lõng) põhipaketid.
Node.js-i kasutavates Fedora hoidlarakendustes on lubatud kinnistada kõik olemasolevad sõltuvused paketti, jagamata ja eraldamata eraldi pakettides olevaid teeke.
Raamatukogude kaasamine vabastab pakettide väiksest segadusest, lihtsustab pakettide hooldust (varem kulutas hooldaja rohkem aega sadade pakettide ülevaatamiseks ja testimiseks raamatukogudega kui programmi põhipaketis), säästab infrastruktuuri konfliktide eest raamatukogude versioonidest ja lahendada probleemid raamatukogu versioonidega linkimisega (hooldajad lisavad paketti testitud ja tootmistestitud versioonid).
Integreerimise negatiivne külg on paranduste tegemise protsessi keerukus raamatukogude nõrgad kohad, mis nõuab kõigi haavatavat teeki sisaldavate pakettide hooldajate koordineeritud tööd. On oht, et pakett unustab haavatava sisseehitatud teegi värskendamise ja see jääb märkamatuks.
Arendajad Debian arutab ka üleminekut sarnasele pakendisõltuvuse integreerimise mudelile. Lisaks Node.js-ile puudutab arutelu Kubernetes platvormi jaoks pakettide loomist ja PHP ja Go keeltes projekte, mille puhul kiputakse jagunema väikesteks sõltuvusteks. Otsust pole veel tehtud, kuid loodetakse, et aja jooksul probleem ainult süveneb ja varem või hiljem on projekt sunnitud midagi tegema.
Pakettide hooldajate probleemide näitena tuuakse gvm (Greenbone Vulnerability Management) turvaskanneri veebiliides gsa (Greenbone Security Assistant).
Debiani saadetud gsa versioon osutus ühildumatuks gvm uuemate versioonidega, kuid gsa ei olnud võimalik uuendada praegusele versioonile, kuna see sisaldab olulisi muudatusi ja kasutab vajalike Node.js teekide allalaadimiseks npm.
Taotletud teeke on liiga palju ja keegi vajab nende hooldamiseks Debianis uute pakettide loomist, kuna Debiani reeglid keelavad väliste komponentide laadimise ehitusprotsessi ajal.
allikas: https://lwn.net/
See raamistike ja raamatukogude killustatus ECMAscriptis on käest ära läinud.
Hea artikkel.