[ON] Debian и Fedora пытаются справиться с проблемой мелких зависимостей

[rssbot]

Дистрибутивы Linux столкнулись с проблемой разрастания зависимостей у проектов. Если для кода на Python, Perl и Ruby число зависимостей держится в разумных пределах, то в проектах на JavaScript практикуется дробление на очень мелкие библиотеки, часто выполняющие одну простую функцию. Репозиторий NPM уже насчитывает более миллиона пакетов, а типовые приложения связываются с сотнями зависимостей, которые, в свою очередь, имеют свои зависимости, что усложняет сопровождение и распространение традиционных пакетов с JavaScript-приложениями в дистрибутивах Linux.

Из-за тесного переплетения зависимостей JavaScript-библиотек обновление в дистрибутиве любого пакета с подобными библиотеками может привести к нарушению работы других пакетов. Проблему усугубляют привязки к версиям - одна библиотека может требовать для стабильной работы одну версию зависимости, а другая - другую. Многие проекты требуют для работы самые свежие версии библиотек, которые не всегда отвечают требованиям дистрибутива к стабильности (в экосистеме Node.js практикуется непрерывное развитие с применением самых свежих версий фреймворков, а дистрибутиву необходима поддержка в течение нескольких лет).

Попытки зафиксировать версии пакетов в дистрибутиве приводят лишь к нарастанию устаревших версий в репозитории, не обновляемых годами. Прекращение сопровождения пакета негативно отражается на множестве других пакетов и приводит к ещё большим проблемам. Кроме того, перекрёстные зависимости приводят к тому, что многие библиотеки 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 в дистрибутиве.


Источник: https://www.opennet.ru/opennews/art.shtml?num=54402
(opennet.ru, основная лента)

[Hephaestus]

для кода на Python, Perl и Ruby число зависимостей держится в разумных пределах

Ну по сравнению с

более миллиона пакетов

может и в разумных, но само по себе число тоже неслабое.
Я тут давеча pandoc собирал (а перед этим ghc, а перед ним Sphinx) - так там, если не ошибаюсь, 137 пакетов в общей сложности получилось по зависимостям. Уже утонуть можно. Для одного pandoc как-то чересчур получается.
И это ещё оно, можно сказать, готовенькое - в SBo лежит.
А на 14.1, помню, сам зависимости разруливал - вообще караул. Что с python, что c ruby, что с haskell.
Либо с этими языками что-то в корне не так, либо я чего-то не понимаю.

[Bizdelnick]

Довели идею модульности до абсурда, а расхлёбывать последствия приходится другим.