Создание конфигурационных пакетов

На устройство пользователя может быть установлено несколько приложений одного вендора. Конфигурационные пакеты используются для доставки данных в приложение. Например, чтобы обновить лицензию в приложении, изменить настройки приложения, добавить в приложение контент. Конфигурационный пакет создаётся разработчиком того же вендора. Конфигурационный пакет заменяет файлы, если имена совпадают. Если один вендор использует и поставляет несколько приложений и несколько конфигурационных пакетов, то разработчик вендора должен обеспечить уникальность имен для папок, в которые будут писать данные разные конфигурационные пакеты. Например:

Вендор 1 Приложение 1 Конф.файл 1

/папка_вендора_1/папка_приложения_1/

/папка_вендора/папка_конф.файла_1/

Вендор 1 Приложение 2 Конф.файл 2

/папка_вендора_1/папка_приложения_2/

/папка_вендора/папка_конф.файла_2/

В противном случае, если имена папок для файлов конфигураций не отличаются, конф.файл_1 может внести незапланированные изменения в Приложение 2.

Пакеты могут размещать данные в /usr/share/common/{доменное_имя}/ и в поддиректориях, например, в /usr/share/common/{доменное_имя}/{название_приложения}, где значения {доменное_имя} и {название_приложения} должны соответствовать тем, которые указаны в .desktop-файле.

• Требования к конфигурационным пакетам
• Использование конфигурационных пакетов
• Алгоритм создания конфигурационного пакета

Требования к конфигурационным пакетам

В .spec-файле пакета необходимо указать путь к конфигурационному файлу, который размещается в каталоге /usr/share/common/{доменное_имя}/ или в соответствующей поддиректории. Если конфигурационные файлы установлены в директорию /usr/share/common/{доменное_имя}/, они будут доступны всем приложениям данного вендора. В случае установки в поддиректорию /usr/share/common/{доменное_имя}/{название_приложения}, доступ к файлам будет ограничен только для приложения этого вендора, соответствующего указанному названию.

Данная папка монтируется в контейнер к другим приложениям того же вендора, которые смогут использовать файлы из неё.

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

В .desktop-файле должны быть прописаны следующие параметры:

    OrganizationName={доменное_имя}
    ApplicationName={название_приложения}
    NoDisplay=true

А так же Exec=sailfish-qml, который используется для qml-only приложений. Параметр Exec нужен для прохождения пакетом валидации, при этом запуск не выполняется, поэтому отсутствие libsailfishapp не мешает созданию конфигурационных пакетов.

Примечание. Библиотека libsailfishapp устарела и будет удалена в будущих релизах. Вместо libsailfishapp следует использовать libauroraapp.

Профиль безопасности конфигурационного пакета может быть любым. Но при использовании профилей Regular или Antivirus необходимо положить в пакет иконки по пути /usr/share/icons/hicolor/IconSize/apps/{название_приложения}.png.

Каждый новый конфигурационный пакет должен увеличивать версию приложения, иначе он не будет установлен.

Использование конфигурационных пакетов

Конфигурационные пакеты позволяют монтировать любые неисполняемые файлы в контейнер с основным приложением.

При установке данных конфигурационного пакета в /usr/share/common/{доменное_имя}/ файлы могут использоваться всеми приложениями того же вендора.

При установке данных конфигурационного пакета в /usr/share/common/{доменное_имя}/{название_приложения} файлы могут использоваться только данным приложением.

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

Пути к файлам, полученным из конфигурационного пакета, можно узнать с помощью метода Aurora::Application::organizationPathTo(const QString &filename), где filename — имя файла из конфигурационного пакета. Вызов указанного метода выполняется из основного приложения. Полный список методов доступен в разделе Данные пользователя.

Алгоритм создания конфигурационного пакета

1. Описать в основном приложении правила использования данных из /usr/share/common/{доменное_имя}/: открыть в нем файл, читать или писать в него.
2. В Аврора IDE создать Qt приложение, использующее пакет, и указать при создании ту же организацию, что и в основном пакете.
3. Удалить из приложения создаваемую по умолчанию папку с исходными кодами и удалить %{_bindir} из .spec-файла.
4. Описать в .desktop-файле Exec=sailfish-qml и NoDisplay=true.
5. Создать конфигурационный файл с данными, нужными основному приложению, и указать в .spec-файле один из двух путей для установки пакета.
6. Добавить в .spec-файл зависимость Requires: libauroraapp-launcher.
7. Подписать конфигурационный пакет ключами профиля безопасности.