Работа с Koji в рамках открытого проекта Fedora

Koji — это программный продукт, позволяющий автоматически и единообразно собирать rpm-пакеты для проекта Fedora. Koji использует утилиту mock, с помощью которой выполняет сборку каждого пакета в отдельном chroot–окружении.

Перед тем как приступить к работе с Koji, рекомендуется определиться с терминологией, чтобы в дальнейшем не путать сущности. Для поддержания единообразия предлагаются следующие определения:

• Пакет (package) — это имя источника rpm, относится ко всему пакету, а не к отдельным сборкам или подпакетам. Например: kernel, glibc и другие.
• Сборка (build) — это определенная сборка пакета, относится ко всем арчам (arches) и подпакетам. Например, kernel–2.6.9–34.EL, glibc–2.3.4–2.19.
• rpm — это определенный арч и подпакет сборки. Например: kernel–2.6.9–34.EL.x86_64, kernel–devel–2.6.9–34.EL.s390, glibc–2.3.4–2.19.i686, glibc–common–2.3.4–2.19.ia64

Koji состоит из нескольких компонентов:

• Koji–Hub — это центр всех Koji операций. Это XML–RPC сервер, который работает в Апаче под mod_wsgi. Koji–Hub находится в пассивном состоянии, получая вызовы XML–RPC и полагаясь только на сборку демонов и другие компоненты для инициации общения. Вообще, Koji–Hub — это единственный компонент, у которого есть прямой доступ к базе данных, и он относится к одному из двух компонентов, у которых есть право записи в файловую систему.
• Kojid — это сборка демона, которая запускается на каждой машине сборки. Основная задача — это опрос входящих запросов сборки и их соответствующая обработка. Kojid работает только с Koji–Hub. У Kojid есть и другие задачи, среди которых, например, создание Kojid свежего buildroot для каждой сборки. Kojid использует mock для сборок. Он написан на Питоне и общается с Koji–Hub через XML–RPC.
• Koji–Web — это набор скриптов, которые запускаются в mod_python и используют шаблонизатор Cheetah для обеспечения веб–интерфейса к Koji. Koji–Web работает как клиент к Koji–Hub, обеспечивая визуальный интерфейс для выполнения ограниченного набора административных действий. Koji–Web показывает большое количество информации и предоставляет средства для конкретных операций, например, операции отмены сборки.
• Koji–client — это написанный на Питоне CLI, который обеспечивает разнообразные ловушки (hook) в Koji. Это позволяет пользователю запрашивать большое количество данных и также выполнять действия, например, добавлять новых участников и инициировать запросы на сборки.
• Kojira — это демон, который поддерживает обновленными репозиторные данные из корня сборки (build root repodata). Он отвечает за удаление лишних корней сборок и очистки после того, как запрос сборки был завершен.

Важные нюансы организации пакетов и использования тегов:

• Koji использует теги, которые отслеживаются в базе данных, но не на диске;
• Koji использует теги, которые поддерживают несколько наследований;
• у каждого тега есть свой список валидных пакетов (наследуемых);
• владение пакетом может быть установлено пре-тегом (наследуемое);
• наследование тегов возможно лучше конфигурировать;
• когда делается сборка, определяется цель, а не тег;
• цель сборки определяет, где следует собрать пакет и какие теги ему присвоить; из этого следует, что имена целей остаются постоянными, тогда как теги меняются в зависимости от релиза.

Скачать исходный код проекта, баг–репорты и присоединиться к электронной рассылке проекта можно здесь (доступно только на английском языке).