Изначальная постановка задачи: sin@
*Задача: На текущий момент сборка или обновление модуля для заданного ядра требует кропотливых действий:
* собрать исходники модуля в отдельный noarch-пакет вида kernel-source-%module_name;
* создать или нбновить шаблон для сборки модуля в виде отдельной ветки для заданного репозитория (например, template/%module_name/%repo_name);
* создать или обновить текущую ветку модуля (например, kernel-modules-%module_name-%kernel_flavour/%repo_name), при этом ветки шаблонов и модулей обычно хранятся в одном репозитории kernel-modules, а для для создания и обновления веток модулей используются скрипты из пакета/репозитория kernel-build-tools;
* после генерации веток с модулями и соответствующих, подписанных gpg-подписью, тегов эти объекты отправляются в удалённый репозиторий;
* отправленные изменения добавляются на сборку, как обычные подзадачи по тегу (команда ssh git.alt task add package_name tag_name).
Кроме сложности алгоритма существует ряд неудобств в связи с выяснением текущей версии и релиза заданного ядра (последняя сборка пакета kernel-image-%kernel_flavour в репозитоии), обновлением последней сборки модуля (ветка %repo_name в репозитории /gears/k/kernel-module-%module_name-%kernel_flavour), использованием скриптов kernel-build-tools.
Требуется упростить процесс сборки модуля путём создания более сложных клиентских скриптов, либо дополнительных команд на сервере. Потенциально вся необходимая информация может доступна на клиентах, но их применение чревато "гонками" (во время формирования задачи, пакеты с модулями и ядром могут быть обновлены).