rber|res has quit [Read error: Connection reset by peer]
xmn has quit [Ping timeout: 272 seconds]
jmiehe has quit [Quit: jmiehe]
florian has quit [Ping timeout: 272 seconds]
mihai- is now known as mihai
paulg has joined #yocto
florian has joined #yocto
sakoman has quit [Quit: Leaving.]
UmbrellaMan has joined #yocto
amitk has quit [Ping timeout: 240 seconds]
<RP>
khem: any idea how we look with meta-oe and the overrides transition?
<UmbrellaMan>
Hey all, in what context does it make sense to use the `VARIABLE_pn-recipename` versus the `VARIABLE_recipename`?
<UmbrellaMan>
For example. I've seen `PREFERRED_VERSION_pn-<recipe_name>` as well as `PREFERRED_VERSION_<recipe_name>`
<RP>
UmbrellaMan: PREFERRED_VERSION is special, it would be _pn- in most other cases
<UmbrellaMan>
Thanks,
<UmbrellaMan>
RP What about `RDEPENDS_${PN}`? It's also having the recipe name directly used as the override?
sakoman has joined #yocto
florian has quit [Ping timeout: 272 seconds]
ant__ has joined #yocto
<kergoth>
UmbrellaMan in that case ${PN} is the same of a package listed in PACKAGES, the fact that it's a recipe name is incidental
<UmbrellaMan>
kergoth (diverging from original question...) Why does it need the _${PN} in the first place? According to the Yocto Chant #1 recipe data is local, so why isn't `RDPENDS` enough?
<kergoth>
UmbrellaMan because one recipe will create many packages.
<kergoth>
we use granular packaging to ease constructing filesystems with just what we want. documentation, development files, etc is all split out into separate binary packages
<kergoth>
RDEPENDS_${PN} only applies to the ${PN} package
<kergoth>
see PACKAGES = in meta/conf/bitbake.conf
<UmbrellaMan>
Thanks, seems those are totally different mechanisms. It's more clear now
<UmbrellaMan>
I'm trying to understand the mechanism on hoe OVERRIDES is used. From what can see, the value of OVERRIDES will change for every recipe and it will contain at least the name of that recipe.
<kergoth>
Only during do_package & friends will the package name be added to OVERRIDES, not generally
<UmbrellaMan>
Yeah, just confirmed it doesn't contain the recipe name always for different recipes... I guess I'm missing the point then.
<UmbrellaMan>
I'm reading it as: "If the string in VARIABLE_<string> also exists in the OVERRIDES variable, the VARIABLE will take that value."
<UmbrellaMan>
Now trying to translate that into open embedded concepts I though it was saying that the overridden variables for a local recipe scope get filtered out from the global scope by the fact that the recipe name is in the OVERRIDES
florian has joined #yocto
<kergoth>
recipe name is not in overrides specifically, and never globally. only during packaging are the *package name* added to it, and only while processing that package while it iterates over the contents of the PACKAGES variable
<UmbrellaMan>
And it does specify a "state" which implies that the current recipe is some kind of an override state.
<kergoth>
pn-${PN} is always in overrides, but ${PN} is only in overrides during packaging.
<UmbrellaMan>
A ok, that makes thing fit into place better. So the `pn-` is kind of like a hacky namespace to prevent recipe names conflicting with other override names?
<UmbrellaMan>
kergoth Cool. Thanks for clarifying things :)
<UmbrellaMan>
So, what I was hoping to achieve before realizing I don't understang the overrides mechanism was to add a the chosen recipe version to an image name.
<UmbrellaMan>
Let me try to thing out loud and see where it get's me. Problem definition: There is a local variable in the image recipe called `IMAGE_LINK_NAME` and I want to expand it with a version of a particular recipe....
<UmbrellaMan>
Let's say I want to have the version of `nano` in my image name because I want to build 20 different images all with different nano versions
<UmbrellaMan>
So to not get lost, having the version in the build image would help me a lot
<UmbrellaMan>
So how can the local namespace of the image recipe get the local PV of the `nano` recipe. Obviously, it can't.
<UmbrellaMan>
But perhaps there is a global alternative. Maybe I can access the override value directly. Something like `IMAGE_LINK_NAME_append="${PV_pn-nano)"`
<UmbrellaMan>
In my current mental model, there isn't a reason for that to work (at least in theory)
jwillikers has quit [Remote host closed the connection]
<UmbrellaMan>
Nope, that doesn't seem to be the case. It isn't resolving `${PV_pn-nano)` to a number, but is treating it as a literal
<kergoth>
correct, recipes cannot access the metadata of other recipes by design