Дистрибутивы Linux столкнулись с проблемой с разрастанием зависимостей у проектов. Если для кода на Python, Perl и Ruby число зависимостей держится в разумных пределах, то в проектах на JavaScript практикуется дробление на очень мелкие библиотеки, часто выполняющие одну простую функцию. Репозиторий NPM уже насчитывает более миллиона пакетов, а типовые приложения связываются с сотнями зависимостей, которые, в свою очередь, имеют свои зависимости, что усложняет сопровождение и распространение традиционных пакетов с JavaScript-приложениями в дистрибутивах Linux.
Из-за тесного переплетения зависимостей JavaScript-библиотек обновление в дистрибутиве любого пакета с подобными библиотеками может привести к нарушению работы других пакетов. Проблему усугубляют привязки к версиям – одна библиотека может требовать для стабильной работы одной версии зависимостей, а другая – другой. Многие проекты требуют для работы самых свежих версий библиотек, которые не всегда отвечают требованиям дистрибутива к стабильности. Попытки стабилизировать версии пакетов приводят лишь на нарастанию устаревших версий в репозитории, не обновляемых годами. Прекращение сопровождения пакета негативно отражается на множестве других пакетов и приводит к ещё большим проблемам. Кроме того, перекрёстные зависимости приводят к тому, что многие библиотеки Node.js становится невозможно деинсталлировать из системы, что, в свою очередь, не позволяет деинсталлировать и другие программы на Node.js.
Для того чтобы справиться с возникшей ситуацией на днях проект Fedora утвердил план по прекращению формированию отдельных пакетов для библиотек, используемых в проектах на базе Node.js. Решено начиная с Fedora 34 поставлять для Node.js только базовые пакеты с интерпретатором, заголовочными файлами, первичными библиотеками, бинарными модулями и основными инструментарми для управления пакетами (NPM, yarn).
В поставляемых в репозитории Fedora приложениях, использующих Node.js, разрешено встраивать все имеющиеся зависимости в один пакет, без дробления и выделения используемых библиотек в отдельные пакеты. Встраивание библиотек позволит избавиться от нагромождения мелкими пакетами, упростит сопровождение пакетов (ранее сопровождающий тратил больше времени на рецензирование и тестирование сотен пакетов с библиотеками, чем на основной пакет с программой), избавит инфраструктуру от конфликтов библиотек и решит проблемы с привязкой к версиям библиотек (сопровождающие будут включать в пакет проверенные в работе и протестированные версии). Обратной стороной интеграции является трудность доведения устранения уязвимостей в библиотеках, которая потребует скоординированной работы сопровождающих всех пакетов, в которые включена уязвимая библиотека.
Переход на аналогичную модель интеграции зависимостей в пакеты (“vendoring”) также обсуждается разработчиками Debian. Кроме Node.js обсуждение затрагивает также создание пакетов для платформы Kubernetes и проектов на языках PHP и Go, для которых также намечается тенденция дробления на мелкие зависимости. Решения пока не принято, но ожидается, что со временем проблема будет лишь усугубляться и рано или поздно проект будет вынужден разрешить интеграцию зависимостей.
В качестве примера проблем, возникающих у сопровождающих пакеты, приводится web-интерфейс gsa (Greenbone Security Assistant) к сканеру безопасности gvm (Greenbone Vulnerability Management). Поставляемая в Debian версия gsa оказалась несовместима с новыми версиями gvm, но обновить gsa до актуального выпуска оказалось невозможно, так как в нём присутствуют существенные изменения и используется npm для загрузки необходимых библиотек Node.js. Запрашиваемых библиотек слишком много и для них требуется создание новых пакетов в Debian, которые должен кто-то сопровождать, так как правила Debian запрещают загрузку внешних компонентов в процессе сборки.
В качестве решения сопровождающий gsa предложил объединить все зависимости в один source-пакет, переместить этот пакет в репозиторий contrib и добавить в него post-install обработчик для загрузки зависимостей. Именно так было сделано для Kali Linux, в котором нет ограничений за загрузку внешних зависимостей при сборке пакетов. В противном случае придётся полностью удалить gsa из Debian, так как у сопровождающего нет ресурсов и желания поддерживать ещё сотню пакетов с библиотеками (основным проектом для сопровождающего является Kali Linux). Альтернативным вариантом также может быть передача работы по созданию требуемых пакетов с библиотеками команде, отвечающей за JavaScript в дистрибутиве.