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

Пакеты могут быть собраны локально (с помощью команд mb2 или sb2 для Sailfish OS Build Engine RUS (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

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

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

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

Исходный код, как правило, размещен внутри одного дерева директорий Git, если первоисточником кода является Sailfish OS. Код может размещаться в корне дерева директорий 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 Ошибка полностью исправлена

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