From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_WEB,SPF_PASS autolearn=no version=3.2.5 Date: Tue, 13 Aug 2013 19:33:40 +0300 From: Igor Vlasenko To: devel@lists.altlinux.org Message-ID: <20130813163340.GA19729@dad.imath.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.21 (2010-09-15) X-imath-kiev-ua-MailScanner-Information: Please contact the ISP for more information X-imath-kiev-ua-MailScanner-ID: 760AD6C9FC7.A2A7D X-imath-kiev-ua-MailScanner: Found to be clean X-imath-kiev-ua-MailScanner-From: vlasenko@imath.kiev.ua Cc: =?utf-8?B?0JTQvNC40YLRgNC40Lkg0JrRg9C70LjQug==?= , Viacheslav Dubrovskyi Subject: [devel] Q: node.js packaging policy X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 16:34:43 -0000 Archived-At: List-Archive: List-Post: Господа, Хочу обсудить полиси для упаковки пакетов 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.