[devel] Q: node.js packaging policy

[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.

Re: [devel] Q: node.js packaging policy

[Igor Vlasenko]

On Tue, Aug 13, 2013 at 07:33:40PM +0300, Igor Vlasenko wrote:
> 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

Сорри, 
Provides: npm(foo) = 1.6.3
Provides: npm(foo) = 1.6

npm(foo) использовать там, где версии ограничены сверху,
а nodejs(foo) оставить для неверсионированных
зависимостей ">=x.y","*","latest".

-- 

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.

Re: [devel] Q: node.js packaging policy

[Viacheslav Dubrovskyi]

13.08.2013 19:33, Igor Vlasenko wrote:
> т.е. думаю, что надо паковать 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
Не очень понятно зачем делать 1.6.3 , 1.6 , 1
А если у нас 2 пакета foo-1.6.3 foo-1.6.4 то на какой должна быть ссылка 
foo@1.6 ?

Не хочется плодить просто ссылки. Логично если бы были только те , 
которые реально стоят.
%{nodejs_sitelib}/foo@1.6.3
%{nodejs_sitelib}/foo@1.6.4
и все.

И следовательно провайдить
Provides: npm(foo) = 1.6.3
Provides: npm(foo) = 1.6.4

>
> Симлинк и requires, если в package.json зависимость на "1.6.x"
> то симлинк на %{nodejs_sitelib}/foo@1.6
> Requires: на npm(foo) = 1.6
Тут если стоит 1.6.x, то логичнее сделать
Requires: на npm(foo) >= 1.6
Requires: на npm(foo) <= 1.7


-- 
WBR,
Viacheslav Dubrovskyi

Re: [devel] Q: node.js packaging policy

[Igor Vlasenko]

On Tue, Aug 13, 2013 at 08:09:00PM +0300, Viacheslav Dubrovskyi wrote:
> 13.08.2013 19:33, Igor Vlasenko wrote:
> >т.е. думаю, что надо паковать 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
> Не очень понятно зачем делать 1.6.3 , 1.6 , 1
> А если у нас 2 пакета foo-1.6.3 foo-1.6.4 то на какой должна быть
> ссылка foo@1.6 ?

Пакеты foo-1.6.3 и foo-1.6.4 имеют 3 компоненты, поэтому в них
и есть только 
%{nodejs_sitelib}/foo@1.6.3
%{nodejs_sitelib}/foo@1.6.4
и все.

ссылка foo@1.6 будет только в пакете foo-1.6. версии, наверно, 1.6.5,
потому что если foo-1.6 версии 1.6.4 то тогда пакет foo-1.6.4
собирать будет не нужно, %{nodejs_sitelib}/foo@1.6.4 и
Provides: npm(foo) = 1.6.4 будут в foo-1.6.
 
> Не хочется плодить просто ссылки. Логично если бы были только те ,
> которые реально стоят.
> %{nodejs_sitelib}/foo@1.6.3
> %{nodejs_sitelib}/foo@1.6.4
> и все.

так и будет. Если где-то еще стоит 1.6.x,
а foo надо обновить до 1.7.0, то просто
вдогонку собираем foo-1.6 последней версии 1.6.5
и закрываем им unmet'ы.

foo-1.6.3 и foo-1.6.4 понадобятся в крайне редких случаях, 
только если среди авторов нашлись очень нехорошие люди, котрые 
явно вписали более старые версии 1.6.3 и 1.6.4 вместо 1.6.x.
 
> Тут если стоит 1.6.x, то логичнее сделать
> Requires: на npm(foo) >= 1.6
> Requires: на npm(foo) <= 1.7

Это и есть c точностью до s/npm/nodejs/ то, 
что прописывает текущий rpm-build-nodejs.
зависимости вида <= мне очень неудобны,
простая проверка на unmets их не ловит,
необходима перегенерация репозитория с вытеснением пакетов.
Я хочу избавиться от зависимостей вида >= + <=,
заменив их эквивалентным =.

-- 

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.