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

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

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

Удаленная сборка пакетов

Пакеты могут быть собраны удаленно с помощью OBS. Подробная информация представлена в статье «Открытый сервис сборки (Open Build Service, OBS)».

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

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

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

mb2 -s [путь к *.spec] -t [цель] build

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

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

mb2 -t SailfishOS-armv7hl build

Выходные RPM-файлы будут находиться в подкаталоге /RPMS. Подробная информация об установке на устройство или цель представлена в статье «Установка пакетов».

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

В некоторых случаях разработчик должен добавить или подключить репозитории для цели, если выводится сообщение о том, что зависимость не может быть установлена. Для этого пользователь должен войти в chroot ScratchBox2.

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

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

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

ssu er [наименование_репозитория]

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

zypper ref -f

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

ssu lr

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

ssu rr [наименование_репозитория]

Для определения того, какой репозиторий содержит необходимый пакет, разработчик должен использовать функцию поиска в build.merproject.org.

Подробная информация о создании целей представлена в «Установка целей для среды сборки».

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

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

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

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

Вход в chroot-окружение Build Engine:

~ $ /srv/mer/sdks/sdk/mer-sdk-chroot

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

PlatformSDK ~ $ sb2 -t SailfishOS-armv7hl -m sdk-build

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

[SB2 sdk-build SailfishOS-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-файле. Примером такого пакета является crda.

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

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

Dumb-пакеты

Dumb-пакеты — устаревший формат, который не должен использоваться. Такие пакеты необходимо преобразовывать в формат tar_git. Пример такой сборки пакетов представлен на сайте.

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

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

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

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

mb2 --help

Создание комментариев к коммитам в Git

Комментарии, должны лаконично и достаточно ёмко описывать суть работы.

Комментарий Примечание
Contributes to xyz#123 Изменение исправляет ошибку с номером задачи в Bugzilla, но не решает проблему полностью
Fixes xyz#124 Ошибка полностью исправлена

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