Closed og-svalery closed 1 year ago
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?
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.
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.
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:
As a result, the
rauc
package has failed to build on thedo_package
stage with the following error:The error seems to be that bitbake has failed to find the
rauc.service
file within the systemd service directory. After looking at therauc
recipes withinmeta-rauc
, it seems like the shared rauc bitbake classes do not check whichPACKAGECONFIG
options have been set. Regarding the error, the following lines withihnmeta-rauc/recipes-core/rauc/rauc-target.inc
are always set regardless of whether the "service" opt-in feature has been provided inPACKAGECONFIG
Possible Solution
These bitbake variables could be updated to first check whether the 'service' feature was specified in PACKAGECONFIG as such: