In my project we have multiple core image (core-image-varA, core-image-varB, etc.)recipes for our machines. The images usually contain different recipes. But for some recipes I would like to install a different version of the recipe based on the image itself, for e.g. the recipe for the firewall rules. I know this can be done with PREFERRED_VERSION, but it has to be specified in a global conf file which I would like to avoid if possible.
Is there a way to select the version of an included recipe in the image recipe itself ? Or some other way that would not involve reading different conf files during a build ? I tried using d.getVar('IMAGE_BASENAME') in local.conf to select the correct PREFERRED_VERSION of the recipe but it did not work. Even though running bitbake -e core-image-varA
printed the desired value of PREFERRED_VERSION_somerecipe, the version that was actually included by bitabke in the build was different.
In my project we have multiple core image (core-image-varA, core-image-varB, etc.)recipes for our machines. The images usually contain different recipes. But for some recipes I would like to install a different version of the recipe based on the image itself, for e.g. the recipe for the firewall rules. I know this can be done with PREFERRED_VERSION, but it has to be specified in a global conf file which I would like to avoid if possible.
Is there a way to select the version of an included recipe in the image recipe itself ? Or some other way that would not involve reading different conf files during a build ? I tried using d.getVar('IMAGE_BASENAME') in local.conf to select the correct PREFERRED_VERSION of the recipe but it did not work. Even though running bitbake -e core-image-varA
printed the desired value of PREFERRED_VERSION_somerecipe, the version that was actually included by bitabke in the build was different.
- This answer suggest to split the recipe into two. Why are you wanting to use specfic versions in different images? Newer software? Different configuration? – Mo_ Commented Mar 17 at 20:45
- 1 @Mo_ The linked answer resolves the issue by create two recipes. My goal is the same but I would prefer to specify a PREFERRED_VERSION to be set by the image recipe if possible. This is because among other things, there are different releases of our devices that are being used by different customers. The task of providing updates or even downgrades to different releases, is made simpler and secure by having the same package but with different versions in different releases. Then for switching to a different release I can just delete the existing package and reinstall the one for the release. – acevans Commented Mar 17 at 22:04
- Thanks, you might want to add the "provide different versions to customer" lines to the question, it helps a lot understanding your situation. – Mo_ Commented Mar 18 at 6:16
1 Answer
Reset to default 1The PREFERRED_VERSION
variable can only be set in conf files, as this answer suggests. That is, either add it to local.conf
or in a recipe in:
meta-something/conf/machine/currently-used-machine.conf
meta-something/conf/distro/currently-used-distro.conf
So your attempted solution does not work with the current Yocto version. Luckily, you stated your actual goal in the comments:
Among other things, there are different releases of our devices that are being used by different customers
This is definitely possible. But as it's always the case with Yocto, you have a plethora of options to achieve your goal:
- Add an individual machine for each device,
- Use Yocto cooker,
- Individual recipes.
- Write your own distro.
1. Individual machines
Changing the machine config makes a lot of sense, if the hardware differs. So if each different device you ship has different hardware, create a machine-foo.conf
for each. Another advantage is, being able to use the MACHINEOVERRIDE in any recipe or config, to select features (or versions) based on which machine is active.
2. Yocto cooker
Yocto cooker is a tool to manage different build configurations. A good example is the pi3 menu. You write a menu.json
for each device variant, where you add:
...
"builds": {
"your-build-config-varA": {
"local.conf": [
"PREFERRED_VERSION_firewall-recipe = '1.2%'",
PREFERRED_VERSION_firewall-recipe = '1.2%'
will be added to the build's local.conf
when you run the build with this command:
cooker cook path/to/menu.json
3. Individual recipes
Put the shared code in a firewall.inc
file. Then your recipes could be named firewall-varA
and look like this:
require firewall.inc
PV = "1.2.3"
Inside the varA
image, install firewall-varA
.
4. Own distro
Creating a separate distro for each device does not make sense, distros are meant to be shared across devices. In theory, you could write your own distro that has a mechanism for changing PREFERRED_VERSION
in images, but it's too much detail for this question.