Dystrybucje Linuksa borykają się z problemem rosnących zależności projektów, chociaż liczba zależności dla kodu Python, Perl i Ruby jest zachowana W rozsądnych granicach projekty JavaScript dzielą się na bardzo małe biblioteki, często wykonujące prostą funkcję.
Repozytorium NPM ma już ponad milion pakietów i typowe zastosowania link do setek zależności, które z kolei mają własne zależności, co utrudnia utrzymanie i dystrybucję tradycyjnych pakietów z aplikacjami JavaScript w dystrybucjach systemu Linux.
Ze względu na ścisłe powiązanie zależności bibliotek JavaScript, aktualizowanie dowolnego pakietu z takimi bibliotekami w dystrybucji może zepsuć inne opakowania.
Powiązania wersji zaostrzają problem: jedna biblioteka może wymagać jednej wersji zależności do stabilnego działania, a inna może wymagać innej.
Wiele projektów wymaga do działania najnowszych wersji bibliotek, które nie zawsze spełniają wymagania stabilności dystrybucji (ciągły rozwój jest praktykowany w ekosystemie Node.js przy użyciu najnowszych wersji frameworków, a dystrybucja wymaga wsparcia przez kilka lat).
Próbuje naprawić wersje pakietów w samej dystrybucji prowadzić do wzrostu liczby przestarzałych wersji w repozytorium, które nie było aktualizowane od lat. Przerwanie konserwacji jednego pakietu ma negatywny wpływ na wiele innych pakietów i stwarza jeszcze więcej problemów.
Ponadto lzależności krzyżowe prowadzą do tego, że wiele bibliotek Deinstalacja Node.js z systemu staje się niemożliwaco z kolei uniemożliwia odinstalowanie innych programów Node.js.
Aby poradzić sobie z tą sytuacją, projekt Fedora niedawno zatwierdził plan zatrzymania domyślnego tworzenia oddzielnych pakietów z bibliotekami używanymi w projektach opartych na Node.js.
Postanowił, zaczynając od Fedory 34, dostarczać tylko podstawowe pakiety dla Node.js z interpreterem, nagłówkami, podstawowymi bibliotekami, plikami binarnymi i podstawowymi narzędziami do zarządzania pakietami (NPM, yarn).
W aplikacjach repozytorium Fedory, które używają Node.js, dozwolone jest osadzenie wszystkich istniejących zależności w pakiecie, bez dzielenia i oddzielania bibliotek używanych w oddzielnych pakietach.
Osadzanie bibliotek pozwoli pozbyć się małego bałaganu w pakietach, uprościć konserwację pakietów (wcześniej opiekun spędzał więcej czasu na przeglądaniu i testowaniu setek pakietów z bibliotekami niż w głównym pakiecie z programem), oszczędza infrastrukturę przed konfliktami bibliotek i rozwiąż problemy z linkowaniem do wersji bibliotek (opiekunowie dołączą do pakietu wersje przetestowane i przetestowane pod kątem produkcji).
Wadą integracji będzie skomplikowanie procesu wnoszenia poprawek luki w bibliotekach, co będzie wymagało skoordynowanej pracy opiekunów wszystkich pakietów, które zawierają podatną bibliotekę. Istnieje niebezpieczeństwo, że pakiet zapomni zaktualizować wbudowaną bibliotekę zawierającą lukę i pozostanie niezauważony.
Twórcy Debian rozważa również przejście na podobny model integracji zależności między pakietami. Oprócz Node.js dyskusja dotyczy tworzenia pakietów na platformę Kubernetes oraz projektów w językach PHP i Go, w przypadku których istnieje tendencja do podziału na małe zależności. Żadna decyzja nie została jeszcze podjęta, ale mamy nadzieję, że z czasem problem będzie się tylko pogarszał i prędzej czy później projekt będzie musiał coś zrobić.
Interfejs sieciowy gsa (Greenbone Security Assistant) dla skanera bezpieczeństwa gvm (Greenbone Vulnerability Management) jest wymieniany jako przykład problemów, które mają opiekunowie pakietów.
Wersja gsa dostarczona przez Debiana okazała się niekompatybilna z nowszymi wersjami gvm, ale nie można było zaktualizować gsa do aktualnej wersji, ponieważ zawiera znaczące zmiany i używa npm do pobrania wymaganych bibliotek Node.js.
Żądanych bibliotek jest zbyt wiele i wymagają one utworzenia nowych pakietów w Debianie, aby ktoś mógł nimi zarządzać, ponieważ zasady Debiana zabraniają ładowania zewnętrznych komponentów podczas procesu budowania.
źródło: https://lwn.net/
Ta fragmentacja ram i bibliotek w ECMAscript wymknęła się spod kontroli.
Dobry artykuł.