Re: Building recipes in multiple flavors for differing images

Stefano Babic

Hi Martin,

On 28.04.22 11:09, Martin Weber wrote:
Hi everybody!
We use yocto to build the system for some of our devices. Given we have multiple use-cases for differing partitions on the device (rescue system; main system in “release” flavor; main system in “development & debug” flavor), we use different custom distros for our build.
With this mail we would like to ask the community what the best practice for our use case are, describe our current approach, and ask whether we can do things in a better way.
The software we use (machine/bsp layer level; software level) in principal is the same (same upstream, internal or 3^rd party), but we need to build them in different ways (e.g., one uses system V init, one uses systemd init; one uses optimized-non-logging versions of the software, another ships debug symbols and enables logging during buildtime; one installs and enables various systemd units, another doesn’t, etc.).
Our solution to this problem is that we have (three) different distros, and use distro overrides to enable/disable/patch/append/delete various bits and pieces throughout the otherwise shared recipes. The “problem” with this is that we need to use different build environments to build our three distros, i.e., we cannot re-use otherwise identical packages.

I do not know if what I did on a couple of projects is cleaner, bu tit is maybe useful to mention. I have often the same topic, and I build a "rescue" and a "production" image, and some of the packages should be different according to the image where they are installed, and I did not want to add dirty trick via post process commands. dropbear, base, etc. are good examples.

What I did is to add variants of the packages, like a base-files-rescue near the standard package, and each image file will select the variant of the package it wants.

To do this, I added a populate_packages:prepend() to a .bbappend of the package, so that I can inject per package the changes I want to have. At the end, it can have a dropbear-rescue and a dropbear packages, and it is not required to have different DISTRO.

I do not know how this can be considered a clean approach, but because it was not yet mentioned, it is nice to have some opinions.


DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@...

Join to automatically receive all group messages.