From: Igor Vlasenko <vlasenko@imath.kiev.ua> To: devel@lists.altlinux.org Cc: "Дмитрий Кулик" <lnkvisitor.ts@gmail.com>, "Viacheslav Dubrovskyi" <dubrsl@gmail.com> Subject: [devel] Q: node.js packaging policy Date: Tue, 13 Aug 2013 19:33:40 +0300 Message-ID: <20130813163340.GA19729@dad.imath.kiev.ua> (raw) Господа, Хочу обсудить полиси для упаковки пакетов 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.
next reply other threads:[~2013-08-13 16:33 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-08-13 16:33 Igor Vlasenko [this message] 2013-08-13 16:39 ` Igor Vlasenko 2013-08-13 17:09 ` Viacheslav Dubrovskyi 2013-08-13 17:32 ` Igor Vlasenko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20130813163340.GA19729@dad.imath.kiev.ua \ --to=vlasenko@imath.kiev.ua \ --cc=devel@lists.altlinux.org \ --cc=dubrsl@gmail.com \ --cc=lnkvisitor.ts@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git