Deploying packages

Deploying Packages

Once a package has been built, it must be deployed to the device (or SDK build environment, in the case of -devel packages). Depending on whether the package was built locally or remotely, there are different ways to deploy the package to the device.

Deploying Local RPMs

For packages built locally with sfdk, the developer will have .rpm files which they wish to deploy. To deploy these packages to a device previously registered within the Sailfish IDE, the developer can use sfdk deploy --manual to transfer the packages to the device. Then, the packages can be installed by issuing the rpm -Uvh --force RPMS/*.rpm command from a devel-su prompt (e.g., devel-su rpm -Uvh --force RPMS/*.rpm). In some cases, rebooting the device may be necessary to force any changes to take effect.

Note that packages installed in this fashion (“sideloaded”) may cause conflicts with packages installed from repositories. Future upgrades will not necessarily succeed cleanly if a sideloaded .rpm with incorrect version information is installed.

Some of the possible issues can be avoided by deploying with zypper, pointing it to the directory where the .rpm files were copied using the -p|--plus-repo option. New packages can be initially deployed with

zypper -p <rpms-dir> --no-gpg-checks -v in <package>...

The --no-gpg-checks is for allowing non-signed packages to be installed. Like the ones that are built with sfdk.

Packages that are already installed can be updated with

zypper -p <rpms-dir> --no-gpg-checks -v dup

With this command zypper upgrades the system using the latest .rpm packages found in . As `sfdk` produces evergrowing version numbers (unless told otherwise), this command always updates to the latest built version found in the directory while obeying package dependencies. When the repositories contain newer package versions, the `--from ~plus-repo-1` option to `zypper dup` helps.

Or if you need to downgrade a specific package to a older version use:

zypper -p <rpms-dir> --no-gpg-checks -v in --oldpackage <package>...

A shorthand syntax exists for this approach – it is the --zypper-dup deployment method:

sfdk deploy --zypper-dup

Add --dry-run to preview the effect before actually applying it.

Deploying Local RPMs into the Build Environment

When multiple packages are modified under a task and build time dependencies exist between those, one needs to ensure that the updated versions of the required packages are available under the build environment. See Working with dependent packages to learn how to achieve that conveniently.

Deploying From Repository

When the Open Build Service builds a package, that package becomes available in a repository (usually, the user’s home project repository). The package may then either be downloaded directly as an .rpm and installed as described in the above section on deploying local .rpm files, or the repository can be added to the device or SDK target as a software update repository, and the device or SDK target can be updated to install the package from that newly added repository.

The OBS repository can be added to the device or SDK target rootfs repository via:

ssu ar <repo_name> <repo_url>

The available packages can then be installed to the device via

devel-su pkcon refresh

followed by

devel-su pkcon install <pkg_name>

or to the SDK via:

zypper ref -f

or refreshing only a specific repository:

zypper ref <repo_name>

and then followed by

zypper in <pkg_name>

from a maintenance shell (e.g., sfdk tools exec SailfishOS-4.3.0.12-armv7hl).

You can use ssu lr to list the available repositories.