Comments 6
Дошли руки пощупать. Структура шаблонов выглядит так, как будто сборка поддерживает только один пакет из src. А если у меня из src десять пакетов собирается? У каждого свой .service, .dirs, .conf, .postinst, .prerm, etc. При том, что дебиановский шабаш в rules ужасен, он он все эти случаи хорошо поддерживает.
На текущий момент такой функционал nxs-build-tools из коробки не предоставляет. Но т.к. в основе сборки пакетов лежит CMake, то принципиально можно доработать cmake-файлы таким образом, чтобы сборка нескольких пакетов в рамках одного проекта стала возможной.
У нас в компании все проекты, в которых применяется данный инструмент, разделены таким образом, чтобы получался один результирующий пакет на проект. Когда-то у нас был один проект, из которого на выходе было три пакета, но потом мы от этой практики отказались, прежде всего, из-за неудобства разработки (но это чисто для нас). И т.к. мы не используем такую практику (да и в принципе я лично видел не так много подобных современных проектов, возможно, конечно, просто не обращал внимание), то и в базовый вариант «многопакетность» не закладывалась. Но nxs-build-tools и был выложен в open source, чтобы он имел возможность развиваться и быть максимально удобным и полезным как можно большему числу людей. Поэтому все вопросы, замечания и идеи помогут его улучить )
Скажите, пожалуйста, Вы могли бы привести какие-то юзкейсы, где бы такая функциональность была бы полезна?
Да, такие юзкейсы постоянно в крупном софте. Из опенсорсного — посмотрите, например, на пакеты cups-* — они все собираются из одного src-deb.
Из проприетарного — у меня прямо сейчас на maintenance java-приложение, из которого собирается 9 разных jar'ников для разных серверов. Каждый идёт в свой пакет (хотя codebase там общая). Более того, у каждого service разные Required=/After= и у каждого пакета разные dependencies по другим пакетам.
Ещё вопрос, который у вас, наверное, не проработан — это управление версией пакета. debian-jenkins-glue делает хорошую версию, которая учитывает и версию в control-файле, и момент сборки.
А gbp позволяет (с использованием pbuilder) гарантировать отсутствие сетевого взаимодейтствия на момент сборки (чтобы никто не упёр из pip'а очередной кривой файл и об этом никто не узнал).
Плюс, build-dependencies позволяют собирать пакет с актуальной зависимостью от системных библиотек (вроде libc).
Апдейт nxs-build-tools — помощника в сборке deb и rpm пакетов