|
Hi,
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 settings.
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: 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. 
Automotive Campus 70 —5708 JZ Helmond, the Netherlands This email may contain information which is privileged and/or confidential. If you received this e-mail in error, please notify us immediately by e-mail and delete the email without copying or disclosing its contents to any other person. Lightyear is a trade name of Atlas Technologies B.V. and is registered at the Dutch Chamber of Commerce under number 67264298.
|
|
|
You have to define an additional distribution I'm afraid. It can share almost everything with the existing distro, but set PREFERRED_PROVIDER differently.
Alex
On Thu, 17 Nov 2022 at 16:22, Maik Vermeulen <maik.vermeulen@...> wrote:
Hi,
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 settings.
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: 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.
Automotive Campus 70 —5708 JZ Helmond, the Netherlands
This email may contain information which is privileged and/or confidential. If you received this e-mail in error, please notify us immediately by e-mail and delete the email without copying or disclosing its contents to any other person. Lightyear is a trade name of Atlas Technologies B.V. and is registered at the Dutch Chamber of Commerce under number 67264298.
|
|
|
Hi Maik, On 11/17/22 16:22, Maik Vermeulen wrote: Hi,
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
settings.
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:
https://urldefense.com/v3/__https://www.yoctoproject.org/pipermail/yocto/2018-June/041378.html__;!!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. https://summit.yoctoproject.org/media/yocto-project-summit-2022-05/submissions/SCYYWD/resources/Demystifying_the_OVERRIDES_mec_2lZOP3n.pdf) 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. Cheers, Quentin
|
|
|
For the record - Yocto chant #1:
Recipe data is local - configuration data is global.
Hi Maik,
On 11/17/22 16:22, Maik Vermeulen wrote:
> Hi,
>
> 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
> settings.
>
> 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:
> https://urldefense.com/v3/__https://www.yoctoproject.org/pipermail/yocto/2018-June/041378.html__;!!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.
https://summit.yoctoproject.org/media/yocto-project-summit-2022-05/submissions/SCYYWD/resources/Demystifying_the_OVERRIDES_mec_2lZOP3n.pdf)
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.
Cheers,
Quentin
|
|
|
