Debian и Fedora пытаются справиться с проблемой мелких зависимостей
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Дистрибутивы 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 в дистрибутиве.
===========
Источник:
OpenNet.RU
===========
Похожие новости
- Главная ссылка к новости (https://linux.slashdot.org/sto...)
- OpenNews: Обратная сторона систем распространения приложений в обход дистрибутивов
- OpenNews: Инцидент с захватом прав на NPM-модуль привёл к сбою в работе проектов, использующих NPM
- OpenNews: Анализ использования фрагментов уязвимых библиотек в исполняемом коде
- OpenNews: Выявление скрытых уязвимостей, возникающих из-за использования стороннего кода
- OpenNews: Оценка безопасности WebKit в дистрибутивах Linux
Похожие новости:
- Лицензия сканера безопасности NMAP признана несовместимой с Fedora
- [PHP, Symfony, Управление разработкой, Управление проектами] У Вас проблемы с legacy — значит, Вам повезло! Распил монолита на PHP
- [Разработка веб-сайтов, JavaScript, Node.JS] Обзор npm 7
- [Тестирование IT-систем, Программирование, Java, IT-стандарты, Промышленное программирование] Принцип слоеного теста
- Fedora отказывается от использовании имени master в репозиториях
- Выпуск пакетного менеджера NPM 7.3
- [*nix, Игры и игровые приставки] Универсальный менеджер приложений (игр)
- [Программирование, Go] Методы организации DI и жизненного цикла приложения в GO
- Третий альфа-выпуск инсталлятора Debian 11 "Bullseye"
- Обновление Debian 10.7
Теги для поиска: #_fedora, #_debian, #_dependency, #_packet, #_npm
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 12:12
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Дистрибутивы 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 в дистрибутиве. =========== Источник: OpenNet.RU =========== Похожие новости
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 12:12
Часовой пояс: UTC + 5