[devel] Q: node.js packaging policy

[Igor Vlasenko]

Господа,

Хочу обсудить полиси для упаковки пакетов nodejs-*,
так как в зависимости от выбора полиси придется переделывать
генератор пакетов и rpm-build-nodejs.

Сейчас rpm-build-nodejs взят из Fedora, генератор пакетов
также генерирует пакеты в соответствии с их полиси.

Чем это чревато?
В Федоре принят героический подход к упаковке nodejs-*.
npm репозиторий с рождения кривой, т.е. многомерный.
Это чревато dll hell, когда при сложной структуре дерева 
зависимостей одновременно необходимы будут разные версии
одной и той же библиотеки.

Поэтому в Федоре хотят его распрямить, т.е. собирать только
одну последнюю версию каждого пакета, при необходимости
патча пакеты, в которых гвоздями пробита старая версия,
чтобы они хотели новую. есть даже специальный макрос: например,
%prep
...
%nodejs_fixdep foo >=1.2

заменит в package.json зависимость на foo на нестрогую.

соответственно, в пакеты обычно пакуется только
%{nodejs_sitelib}/name, не
%{nodejs_sitelib}/name на version.
симлинки на зависимости тоже делаются на %{nodejs_sitelib}/name.
И только иногда, когда явно никуда не деться от необходимости 
держать несколько версий, то пакуется
%{nodejs_sitelib}/name@<главная часть версии>
и на нее делаются симлинки.

Этот героический подход хорош тем, что 
репозиторий меньше по объему за счет исключения не нужных дубликатов,

но плох тем, что
А) при обновлении пакета на новую версию иногда бывает необходимо 
вручную или автоматизированно корректировать его версии в зависимостях
других пакетов.
Б) При использовании другой версии пакета нет гарантии,
что зависящие от него модули будут работать правильно.
Язык интерпретируемый, проверки компиляцией нет,
и даже если вроде бы работает, нет гарантии, что не сломается
при определенных условиях во время выполнения.

Соответственно, если собирать в отдельный репозиторий,
то на объем сизифа это не повлияет - плюсы их подхода не существенны.

А проблемы A) и Б) менее существенны для Федоры, у которых
больший объем пользователей, и, следовательно, лучше тестирование
их девиаций, и гораздо более критичны у нас, где для проблемы А)
нет лишних рабочих рук, а для B) нет круга пользоваателей.

Плюс, в Федоре пока потянули только 200+ пакетов,
чтобы прямо собрать хотя бы пару тысяч пакетов, им понадобится
Чак Норрис.

IMHO, не нужно пытаться выпрямить кривое, горбатого могила
исправит, а надо собирать в точности по лекалу выхлопа npm install.

Даже если объем репозитория распухнет в 3-4 раза за счет 
версионированных compat пакетов, то это не приведет к увеличению
объема работы - пакеты будут генерироваться роботом по списку,
размер списка не так важен.

А зато раз в пакетах будет тот же выхлоп npm install,
только зарегистрированный в базе rpm, то это позволит 
в случае любых проблем идти в апстрим, так как 
абсолютно те же проблемы будут и при ручном использовании
npm, но при ручном использовании npm они скрыты, и вылезут
во время выполнения, а при упаковке в rpm они сразу будут
видны как unmets, проблемы с бинарниками и т.д.

т.е. думаю, что надо паковать foo 1.6.3
как набор %{nodejs_sitelib}/foo и симлинки
%{nodejs_sitelib}/foo на 1.6.3
%{nodejs_sitelib}/foo на 1.6
%{nodejs_sitelib}/foo на 1

Генерировать не Provides: nodejs(foo) = 1.6.3
а 
Provides: npm(foo) = 1.6.3
Provides: npm(foo) = 1.6
Provides: npm(foo) = 1
и
Provides: nodejs(foo) = 1.6.3
, которую использовать вместо Provides: npm(foo) = latest

Симлинк и requires, если в package.json зависимость на "1.6.x"
то симлинк на %{nodejs_sitelib}/foo на 1.6
Requires: на npm(foo) = 1.6

если в package.json зависимость на latest (*)
то симлинк на %{nodejs_sitelib}/foo
Requires: на nodejs(foo)

Если вышел foo 1.7.0, то роботом собрать
nodejs-foo-1.6 версии 1.6.3,
где будет только
%{nodejs_sitelib}/foo на 1.6.3
%{nodejs_sitelib}/foo на 1.6
и нет %{nodejs_sitelib}/foo и %{nodejs_sitelib}/foo на 1.
и соотв. Provides: только
Provides: nodejs(foo) = 1.6.3
Provides: nodejs(foo) = 1.6

Как такой вариант?
Выглядит нормально или я чего-то не учитываю?

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.