Re: Image dependent variables/files in included recipes

Quentin Schulz

Hi Maik,

On 11/17/22 16:22, Maik Vermeulen wrote:
Depending on the image that's being built, e.g. development vs. production,
we would like to be able to include different user passwords and firewall
We know this can be achieved by just having two different recipes that do
the same thing, but with different variables or included files. However, we
were wondering if there is a neater way?
We saw this post:;!!OOPJP91ZZw!k-UkKru_mKI6U4p8UgDfH_VEh1-qar1kiQuqcmnyrETRAnubF79KykqR7VGaRu47i1Ws7n8CAagOJBqEFBB3goTxmBkgn8-qL3X383IHnKva$
which seems to do what we want, because one recipe can install
recipe-development, and the other can install recipe-production, while the
recipe itself can then implement what needs to happen for either.
However, other recipes included in the images can also depend on recipe,
and they shouldn't depend on one specifically. They should accept that
either recipe-development or recipe-production is included. Currently we
see that both the generic recipe and the specific recipe used by the image
are built and overwrite each other.
What would be a neat way to achieve two variants of a recipe, and having
different contents and settings in them?
Or, can we solve that other included recipes depend on one of the variants,
instead of on the generic one.
Development vs production is solved by using different distros.

You can then have the same recipe but with different files (see (DISTRO)OVERRIDES mechanism for SRC_URI file:// files, c.f. and/or different variables via FOO:dev-distro or FOO:append:dev-distro for example.

You could also have different recipes both PROVIDES'ing the same virtual recipe and then have PREFERRED_PROVIDER_my-recipe = "my-recipe-dev" in your dev-distro.conf file.

Two distros is usually overkill when you have very small and non-invasive differences between your dev and prod images (e.g. an additional package, or a lone package that needs to be slightly different). In that scenario, a "drity" solution is to have two recipes and have the final image pick the appropriate package. But this quickly does not scale well once you have recipes/packages depending on those or if you have more than two flavors to support.

The best practice is to use two distros.


Join to automatically receive all group messages.