Debian in Fedora poskušata odpraviti težavo z odvisnostmi

Distribucije Linuxa se soočajo s problemom naraščajočih odvisnosti projektov, čeprav ohrani se število odvisnosti za kodo Python, Perl in Ruby Projekti JavaScript v razumnih mejah vadijo delitev na zelo majhne knjižnice, ki pogosto opravljajo preprosto funkcijo.

Skladišče NPM ima že več kot milijon paketov in tipične aplikacije povezava na stotine odvisnosti, ki pa imajo svoje odvisnosti, kar otežuje vzdrževanje in distribucijo tradicionalnih paketov z aplikacijami JavaScript v distribucijah Linuxa.

Zaradi tesnega prepletanja odvisnosti knjižnic JavaScript posodobitev katerega koli paketa s takšnimi knjižnicami v distribuciji lahko zlomi druge pakete.

Povezave različic poslabšajo težavo: ena knjižnica lahko zahteva, da ena različica odvisnosti deluje stabilno, druga pa druga.

Številni projekti potrebujejo najnovejše različice knjižnic, ki ne izpolnjujejo vedno zahtev glede stabilnosti distribucije (stalni razvoj se izvaja v ekosistemu Node.js z uporabo najnovejših različic okvirov, distribucija pa potrebuje podporo več let).

Poskusi popraviti različice paketov samo v distribuciji vodijo k povečanju zastarelih različic v odlagališču, ki se že leta ne posodablja. Motnje vzdrževanja enega paketa negativno vplivajo na številne druge pakete in povzročajo še več težav.

Poleg tega je lnavzkrižne odvisnosti vodijo do dejstva, da številne knjižnice v Ljubljani Node.js je nemogoče odstraniti iz sistemakar pa preprečuje odstranitev drugih programov Node.js.

Da bi rešili to situacijo, je projekt Fedora nedavno odobril načrt za ustavitev privzetega oblikovanja ločenih paketov s knjižnicami, ki se uporabljajo v projektih, ki temeljijo na Node.js.

Od Fedore 34 se je odločil, da bo za Node.js dobavil samo osnovne pakete z razlagalnikom, glavami, primarnimi knjižnicami, binarnimi datotekami in osnovnimi orodji za upravljanje paketov (NPM, preja).

V aplikacijah za shranjevanje Fedora, ki uporabljajo Node.js, dovoljeno je vdelati vse obstoječe odvisnosti v paket, ne da bi delili in ločili knjižnice, ki se uporabljajo v ločenih paketih.

Vdelava knjižnic se bo znebila nereda v majhnih paketih, poenostavila vzdrževanje paketov (prej je vzdrževalec več časa pregledoval in testiral na stotine paketov s knjižnicami kot v glavnem paketu s programom), rešil infrastrukturo pred konflikti knjižnic in odpraviti težave s povezovanjem z različicami knjižnic (vzdrževalci bodo v paket vključili preizkušene in preizkušene različice).

Slaba stran integracije bo zapletanje postopka uvajanja popravkov do ranljivosti v knjižnicah, kar bo zahtevalo usklajeno delo vzdrževalcev vseh paketov, ki vključujejo ranljivo knjižnico. Obstaja nevarnost, da bo paket pozabil posodobiti ranljivo vgrajeno knjižnico in bo paket ostal neopažen.

Razvijalci Debian razpravlja tudi o prehodu na podoben model integracije odvisnosti od paketov. Razprava se poleg Node.js dotakne tudi ustvarjanja paketov za platformo Kubernetes in projektov v jezikih PHP in Go, pri katerih se tendenca deli na majhne odvisnosti. Odločitev še ni bila sprejeta, upamo pa, da se bo težava sčasoma samo poslabšala in bo slej ko prej projekt prisiljen v nekaj ukrepati.

Kot primer težav, ki jih imajo vzdrževalci paketov, je naveden spletni vmesnik gsa (Greenbone Security Assistant) za gvm (Greenbone Vulnerability Management).

Izkazalo se je, da različica gsa, ki jo pošilja Debian, ni združljiva z novejšimi različicami gvm, vendar gsa ni bilo mogoče posodobiti na trenutno različico, saj vsebuje pomembne spremembe in uporablja npm za prenos potrebnih knjižnic Node.js.

Zahtevanih knjižnic je preveč in zahtevajo ustvarjanje novih paketov v Debianu, da bi jih lahko nekdo vzdrževal, saj pravila Debiana med postopkom gradnje prepovedujejo nalaganje zunanjih komponent.

vir: https://lwn.net/