cabextract-native brings dependency on meta-oe

[ricardosalveti]

firmware-woa depends on cabextract-native, which is only available in meta-oe (https://git.openembedded.org/meta-openembedded/commit/meta-oe/recipes-support/cabextract?id=3eb7dd257b74b04fe6d513144eb988159fa501a0), and this layer only depends on oe-core.

@lumag since we only have one dependency on meta-oe, should we bring that recipe in or do you think we should depend on meta-oe just for it?

[ricardosalveti]

linux-qcom-uki also depends on a recipe from meta-oe: python3-pefile-native

[lumag]

I'll move firmware-woa to dynamic-layers/openembedded-core, thanks for the notice. As for the python3-pefile-native, I think we should move it to oe-core. Would you mind posting it? This way we can get UKI support enabled in the OE-Core too.

[ricardosalveti]

Moving firmware-woa related recipes under dynamic-layers/meta-oe should fix the dependency itself, but from my perspective it is a bit weird that a firmware recipe (which is core to the platform) is depending on meta-oe. In the end this won't cause issues because mostly everyone is also adding meta-oe as part of their build.

I will have a look at python3-pefile.

[lumag]

I went on and checked existing BSP layers. I think the goal is to be pretty conservative regarding dependencies. E.g. meta-arm-bsp has machine-specific depends to reduce overall dependency list. Granted that WoA machines are not a main target audience for Yocto I think it's fine to use dynamic-layers and then add LAYERRECOMMENDS to point out that meta-oe is suggested, but not required.

[quic-vkraleti]

I added esp-qcom-image to CI. Builds started failing now, with a dependency on python3-pefile-native. What should be the next course of action?

[lumag]

I'll add meta-oe to BBLAYERS to unbreak CI.