Сборка установочных пакетов

После авторизации в среде сборки появляется возможность собирать пакеты, настраивать зависимости сборки и её окружение.

Некоторые команды необходимо запускать от имени корневого пользователя su. Также после запуска команды su возможно выполнять всю работу от имени корневого пользователя.

Пакеты могут быть собраны локально (с помощью команд mb2 или sb2 для Build Engine).

• Локальная сборка пакетов
• Установка недостающих зависимостей
• Добавление пакетов для конкретного таргета
• Локальная сборка бинарных файлов
• Форматы пакетной сборки
  • Структура пакетной сборки tar_git
  • Расположение исходного кода пакета tar_git в Git
• Создание журнала изменений

Локальная сборка пакетов

После установки среды сборки и настройки таргетов возможно начать локальную сборку пакетов для целевой архитектуры с использованием скрипта mb2 (вызывается из Build Engine). Данный скрипт является оболочкой Scratchbox2 (sb2) и rpmbuild, предназначенной для оптимизации создания пакетов из исходных репозиториев, предоставляемых в spec-файле.

Скрипт mb2 для сборки пакета вызывается следующим образом:

mb2 -s <путь_к_*.spec> -t <наименование_таргета> build

При наличии единственного spec-файла, содержащегося в подкаталоге rpm, первый параметр является необязательным.

mb2 -t <наименование_таргета> build # поиск SPEC-файла в RPM

Команда, представленная ниже, собирает большинство проектов и упаковывает результаты в RPM-файлы, готовые для установки (при условии, что таргет AuroraOS-4.0.1.20-base-armv7hl был установлен):

mb2 -t AuroraOS-4.0.1.20-base-armv7hl build

Установка недостающих зависимостей

Если выводится сообщение о том, что зависимость не может быть установлена, разработчику необходимо добавить или подключить репозитории для таргета.

Для добавления репозитория следует использовать команду:

ssu ar <наименование_репозитория> <URL_репозитория>

Для подключения репозитория следует использовать команду:

ssu er <наименование_репозитория>

Для вывода списка известных репозиториев следует использовать команду:

ssu lr

Для удаления репозитория следует использовать команду:

ssu rr <наименование_репозитория>

Утилита zypper тоже даёт возможность работать с репозиториями и пакетами:

zypper lr # список репозиториев
zypper ref # обновление репозиториев
zypper update # обновление пакетов
zypper se packagename # поиск пакетов
zypper in packagename # установка пакетов
zypper info packagename # информация о пакете
zypper info -t pattern patternname # информация о шаблоне
zypper verify # проверка зависимостей
zypper packages --orphaned # очистка пакетов
zypper remove --clean-deps packagename # удаление пакета

Обновление среды для конкретного таргета:

sb2 -t <наименование_таргета> -m sdk-install -R zypper ref
sb2 -t <наименование_таргета> -m sdk-install -R zypper update

Добавление пакетов для конкретного таргета

Добавить пакеты для конкретного таргета можно с помощью следующих команд:

1. Зайти в таргет:

   sb2 -t <наименование_таргета> -m sdk-install -R
   

2. Найти нужный пакет:

   zypper search <название_пакета>
   

3. Установить пакет:

   zypper install <полное_название_пакета>
   

Локальная сборка бинарных файлов

Сборка полного RPM-пакета не является обязательной. Например, во время тестирования достаточно собрать бинарный файл из проекта (предпочтительно на основе Qt).

В этом случае необходимо собрать проект в Scratchbox2.

Последовательность команд, необходимых для сборки проекта на основе Qt:

Вход в ScratchBox2 в режиме сборки:

AuroraSDK ~ $ sb2 -t AuroraOS-<номер_релиза>-base-<архитектура> -m sdk-build

Пример:

AuroraSDK ~ $ sb2 -t AuroraOS-5.1.5-base-armv7hl -m sdk-build

Запуск qmake && make ScratchBox2:

[SB2 sdk-build AuroraOS-5.1.5-base-armv7hl] ~ $ cd ~/<наименование_каталога> && qmake && make

Полученный бинарный код ARMv7 может быть скопирован на устройство с помощью команды scp и запущен напрямую.

Форматы пакетной сборки

Структура пакетной сборки tar_git

Пакеты в ОС Аврора в основном упакованы в формат tar_git. Данный формат относительно прост и, при соблюдении базовых правил, такие инструменты как mb2, функционируют корректно, а значит с большой вероятностью, пакет соберется корректно.

RPM-файлы <имя_файла>.spec расположены в rpm/<имя_файла>.spec. Наличие файла <имя_файла>.changes необязательно, но необходимо, если файлы размещены в rpm/<имя_файла>.changes. Кроме того, все остальные файлы в каталоге rpm/ должны быть отмечены как SourceX: или PatchX:.

Расположение исходного кода пакета tar_git в Git

Исходный код, как правило, размещен внутри одного дерева директорий Git, если первоисточником кода является ОС Аврора. Код может размещаться в корне дерева директорий Git, в каталоге Src или в аналогичном месте в зависимости от пакета. Примером такого пакета является mce.

Если первоисточник пакета существует извне и не содержит значительных изменений для исходного кода, то источники обычно располагаются в каталоге с таким же наименованием, что и у пакета в *.spec-файле.

В случае если существует множество модификаций, обращающихся к первоисточнику, но не являющихся его частью, то подмодуль обычно называют первоисточником (upstream), как и соответствующий каталог в *.spec-файле, который содержит копию первоисточника с модификациями. Примером такого пакета является connman.

В некоторых случаях в дереве директорий Git подмодули отсутствуют, если первоисточник — архив *.tar, *.cvs или *.svn, из-за чего подмодуль Git не может быть создан.

Создание журнала изменений

Журнал изменений генерируется из коммитов Git в пакетах tar_git. Каждая строка добавляется в журнал изменений в следующем формате:

[key] Summary. Contributes to xyz#123
[packaging] Updated Y to version X. Fixes xyz#124

Для вызова справки о журнале изменений, выполните команду внутри SDK:

mb2 --help