rauc_1.10 does not support building without the 'service' PACKAGECONFIG opt-in feature

[og-svalery]

Context

I am building v1.10 of the rauc package using the meta-rauc kirkstone upstream recipe (meta-rauc/recipes-core/rauc/rauc_1.10.bb). I am only interested in using the "json" opt-in feature of the rauc package.

Problem

In order to only use the "json" feature, I have specified the following:

PACKAGECONFIG:pn-rauc ?= "json"

As a result, the rauc package has failed to build on the do_package stage with the following error:

ERROR: rauc-1.10-r0 do_package: Didn't find service unit 'rauc.service', specified in SYSTEMD_SERVICE:rauc-service. 
ERROR: Logfile of failure stored in: .../rauc/1.10-r0/temp/log.do_package.4099807
ERROR: Task (.../poky/../meta-rauc/recipes-core/rauc/rauc_1.10.bb:do_package) failed with exit code '1'

The error seems to be that bitbake has failed to find the rauc.service file within the systemd service directory. After looking at the rauc recipes within meta-rauc, it seems like the shared rauc bitbake classes do not check which PACKAGECONFIG options have been set. Regarding the error, the following lines withihn meta-rauc/recipes-core/rauc/rauc-target.inc are always set regardless of whether the "service" opt-in feature has been provided in PACKAGECONFIG

PACKAGES =+ "${PN}-service"
SYSTEMD_SERVICE:${PN}-service = "rauc.service"
SYSTEMD_PACKAGES += "${PN}-service"
RDEPENDS:${PN}-service += "dbus"

Possible Solution

These bitbake variables could be updated to first check whether the 'service' feature was specified in PACKAGECONFIG as such:

SYSTEMD_SERVICE:${PN}-service = "${@bb.utils.contains('PACKAGECONFIG','service','${PN}-service','',d)}"

[ejoerns]

You are right, despite not being frequently used, it should be possible to build (and install) rauc without the 'service' feature being enabled.

May I ask for your use case for that you want to disable RAUC's server/client split-up? Is this because of size limitations on the target and D-Bus avoidance?

Since #282 is a direct implementation of your suggestion, should we add a Suggested-by from you there?

[swaeberle]

We are re-using the rauc package for a special deployment image relying on the --override-boot-slot argument. Our productive image could also use the service variant.

It would be great to have a rauc-standalone package for such a special purpose, but rauc-service installed in the real image.

[jluebbe]

We are re-using the rauc package for a special deployment image relying on the --override-boot-slot argument. Our productive image could also use the service variant.

The rauc.external kernel command line option is intended for that case.