rauc: split package into 'rauc' for binary and 'rauc-conf' for configuration

[ejoerns]

rauc: split package into 'rauc' for binary and 'rauc-conf' for configuration

This allows to build 'rauc' with default TUNE_PKGARCH while only 'rauc-conf' needs to be build for MACHINE_ARCH as it contains MACHINE-specific configuration.

Another point is that the RAUC configuration may not only by MACHINE-specific but may also differ between images (for the same MACHINE).

The rauc target package now RRECOMMENDS rauc-conf to pull this in by default.

For providing your own configuration, either bbappend the existing rauc-conf recipe, write a new one that provides 'virtual-rauc-conf' and set PREFERRED_PROVIDER_virtual-rauc-conf or just write a custom one and add it to your image's IMAGE_INSTALL list (or any packagegroup).

Either way, this requires migration in your rauc recipe(s)!

[ejoerns]

rebased onto master

[OnkelUlla]

Just two suggestions.

[jluebbe]

With the RDEPENDS += "rauc-conf" it should be obvious enough to people updating from previous versions that the system.conf would need to move to rauc-conf. Perhaps add a hint regarding that to the commit message nevertheless?

[mschwan-phytec]

@ejoerns Any news on this PR? Would be nice to see it being merged. 🙂 It would make custom configurations a lot easier to handle.

[ejoerns]

Indeed.

And I currently work myself on a project where this should be quite useful, too.
If I find the time, I will test this again in and make it ready for being merged.

[philippderdiedas]

well...
how about now? (he asked nicely because does not want to fork it himself)

[ejoerns]

Rebased onto the current master and applied some minor changes.

I was unsure about how strongly I wanted to couple rauc and rauc-conf and decided to add a RRECOMMENDS to a virtual package indirection since I assume that people not only need to want/need to append the rauc-conf recipe but likely provide their own recipes instead. E.g. for differentiating variants on the image level, this is required anyway.

Suggestions or objections welcome.

[jluebbe]

I was unsure about how strongly I wanted to couple rauc and rauc-conf and decided to add a RRECOMMENDS to a virtual package indirection since I assume that people not only need to want/need to append the rauc-conf recipe but likely provide their own recipes instead. E.g. for differentiating variants on the image level, this is required anyway.

With this change, anyone using NO_RECOMMENDATIONS in their image will have no config in their image. If you want to use per-image configs, you can easily drop the RDEPENDS via a bbappend. A comment for that case should be enough.

[ejoerns]

I was unsure about how strongly I wanted to couple rauc and rauc-conf and decided to add a RRECOMMENDS to a virtual package indirection since I assume that people not only need to want/need to append the rauc-conf recipe but likely provide their own recipes instead. E.g. for differentiating variants on the image level, this is required anyway.

With this change, anyone using NO_RECOMMENDATIONS in their image will have no config in their image. If you want to use per-image configs, you can easily drop the RDEPENDS via a bbappend. A comment for that case should be enough.

I wanted to avoid having to bbappend the recipe file for this case and assumed that having no config at all might be noticed.

Note that e.g. systemd pulls in systemd-conf via RRECOMMENDS only, too.

But maybe using RDEPENDS is safer for the transition in the first round, anyway.

[jluebbe]

I wanted to avoid having to bbappend the recipe file for this case and assumed that having no config at all might be noticed.

Note that e.g. systemd pulls in systemd-conf via RRECOMMENDS only, too.

OK. Then it's consistent, and it retract my criticism.

But maybe using RDEPENDS is safer for the transition in the first round, anyway.