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

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

Вендор 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 не мешает созданию конфигурационных пакетов.

Профиль безопасности конфигурационного пакета может быть любым. Но при использовании профилей 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. Подписать конфигурационный пакет ключами профиля безопасности.