Дистрибутиви Linux стикаються з проблемою збільшення залежностей проектів, хоча кількість залежностей для коду Python, Perl та Ruby зберігається У розумних межах проекти JavaScript практикують поділ на дуже маленькі бібліотеки, які часто виконують просту функцію.
У сховищі NPM вже понад мільйон пакетів і типові програми посилання на сотні залежностей, які в свою чергу мають свої залежності, що ускладнює підтримку та розповсюдження традиційних пакетів із програмами JavaScript на дистрибутивах Linux.
Через щільне переплетення залежностей бібліотек JavaScript, оновлення будь-якого пакету з такими бібліотеками у дистрибутиві це може зламати інші пакети.
Прив'язка версій посилює проблему: одна бібліотека може вимагати стабільної роботи однієї версії залежності, а інша - іншої.
Для багатьох проектів потрібні найновіші версії бібліотек, які не завжди відповідають вимогам стабільності дистрибутиву (постійний розвиток практикується в екосистемі Node.js з використанням останніх версій фреймворків, і дистрибутив потребує підтримки протягом декількох років).
Спроби виправити версії пакетів лише в дистрибутиві призводять до збільшення застарілих версій у сховищі, яке не оновлювалось роками. Порушення обслуговування одного пакета негативно впливає на багато інших пакетів і створює ще більше проблем.
Крім того, lперехресні залежності призводять до того, що багато бібліотек Росії Node.js стає неможливо видалити з системищо, у свою чергу, заважає вам видалити інші програми Node.js.
Щоб вирішити цю проблему, нещодавно проект Fedora затвердив план припинення формування за замовчуванням окремих пакетів з бібліотеками, що використовуються в проектах на основі Node.js.
Він вирішив, починаючи з Fedora 34, поставляти лише базові пакети для Node.js з інтерпретатором, заголовками, первинними бібліотеками, двійковими файлами та основними інструментами управління пакетами (NPM, пряжа).
У додатках-сховищах Fedora, які використовують Node.js, дозволяється вбудовувати всі існуючі залежності в пакет, не розділяючи та не відокремлюючи бібліотеки, що використовуються в окремих пакетах.
Вбудовування бібліотек позбавить від дрібної захаращеності пакунків, спростить обслуговування пакетів (раніше супровідник витрачав більше часу на перегляд і тестування сотень пакетів з бібліотеками, ніж в основному пакеті з програмою), врятує інфраструктуру від конфліктів бібліотек та вирішити проблеми із посиланням на версії бібліотек (супровідники включатимуть у пакет перевірені та перевірені версії).
Недоліком інтеграції буде ускладнення процесу внесення виправлень до вразливостей у бібліотеках, що вимагатиме злагодженої роботи супровідників усіх пакетів, що включають вразливу бібліотеку. Існує небезпека того, що пакет забуде оновити вразливу вбудовану бібліотеку, і пакет залишиться непоміченим.
Розробники Debian також обговорює перехід на подібну модель інтеграції залежностей від пакетів. Окрім Node.js, обговорення стосується створення пакетів для платформи Kubernetes та проектів на мовах PHP та Go, для яких існує тенденція поділятися на невеликі залежності. Рішення ще не прийнято, але є надія, що з часом проблема лише погіршиться, і рано чи пізно проект буде змушений щось робити.
Веб-інтерфейс gsa (Greenbone Security Assistant) для сканера безпеки gvm (Greenbone Vulnerability Management) наводиться як приклад проблем, які виникають у розробників пакетів.
Відправлена Debian версія gsa виявилася несумісною з новими версіями gvm, але оновити gsa до поточної версії не вдалося, оскільки вона містить суттєві зміни та використовує npm для завантаження необхідних бібліотек Node.js.
Запитаних бібліотек занадто багато, і вони вимагають створення нових пакетів у Debian, щоб хтось міг їх підтримувати, оскільки правила Debian забороняють завантажувати зовнішні компоненти під час процесу збірки.
Фуенте: https://lwn.net/
Ця фрагментація фреймворків та бібліотек у ECMAscript вийшла з-під контролю.
Хороша стаття.