We’re managing a distro layer which supports several targets, primarily qemu and Raspberry Pi 3. We have a single set of layers which are always enabled and the target is selected using the MACHINE variable as is usual when using Yocto Project. We also need to be enable to enable or disable Mender support as an IMAGE_FEATURE or DISTRO_FEATURE.
The meta-raspberrypi BSP layer is an example of what should happen here. We can always include the meta-raspberrypi layer and it does not force us to build for a Raspberry Pi target, we can still successfully build for a qemu target. The behaviour of the qemu images is not changed by meta-raspberrypi.
The Mender meta-mender-raspberrypi layer causes problems for us though - this layer forcibly changes MENDER_FEATURES_ENABLE and MENDER_FEATURES_DISABLE. Unconditionally disabling mender-grub prevents us from building for targets that use grub (such as qemu). Unconditionally enabling mender-image-sd leads to a long list of errors if the mender-image feature isn’t also enabled.
To fix this the meta-mender-raspberrypi layer should only modify these variables if the underlying mender-image feature is already enabled and the target MACHINE is actually a Raspberry Pi device.
These would be acceptable fixes and pull-requests are welcome.
The meta-raspberrypi BSP layer is an example of what should happen here. We can always include the meta-raspberrypi layer and it does not force us to build for a Raspberry Pi target, we can still successfully build for a qemu target. The behaviour of the qemu images is not changed by meta-raspberrypi.
I am familiar with how this works in meta-raspberrypi, but I am personally not a big fan of mixing BSP layers in to single build environment and yes it might work for meta-raspberrypi, but this is not true for many other BSP layers.
But this might not be the place for such an discussion and would gladly talk about it at next ELCE
The meta-raspberrypi BSP layer is an example of what should happen here. We can always include the meta-raspberrypi layer and it does not force us to build for a Raspberry Pi target, we can still successfully build for a qemu target. The behaviour of the qemu images is not changed by meta-raspberrypi.
I am familiar with how this works in meta-raspberrypi, but I am personally not a big fan of mixing BSP layers in to single build environment and yes it might work for meta-raspberrypi, but this is not true for many other BSP layers.
This is the way Yocto Project BSP layers should work though - meta-raspberrypi is an example of a layer that does this correctly.
ELCE is quite a way off yet - we’re hoping to get a release of our distro with support for Mender.io integration long before that.
I’d recommend the following changes but I’ve got limited ability to test them here for anything other than Raspberry Pi and qemu targets. Could you take a look and let me know what you think? I don’t want to open a formal pull request if these changes are likely to break anything.
The changes look good to me, but would like a comment from @kacf. The intention was I believe to use MENDER_FEATURES_ENABLE/DISABLE to modify features, and this creating a “backdoor”.
But this could also work in meta-mender-raspberrypi?
This is the way Yocto Project BSP layers should work though - meta-raspberrypi is an example of a layer that does this correctly.
According to what reference/specification/documentation/recommendation, is this the way Yocto Project BSP layers should work?
I understand that this has been adopted by meta-raspberrypi and I know that meta-angstrom is setup relying on this assumption. But I am not aware of any other distributions doing it this way and many rely on per board environments with configuration fragments etc…
We have a lot more integration layers in meta-mender-community which currently do not comply to this approach, and would get to the bottom of this to know how to enforce this moving forward.
It should be said that I understand the benefits of this and generally would prefer this, but it is not clear to me that “this is the way Yocto Project BSP layers should work”, if it is not “cemented” somewhere.
ELCE is quite a way off yet - we’re hoping to get a release of our distro with support for Mender.iointegration long before that.
I did not mean to hold any changes until then, and just consider this easier to discuss in person.
Regardless of how the layers “should work”, my take is that such fixes are acceptable as long as they:
solve some not too far fetched use case
are non-intrusive
do not complicate things
We already have many examples of such default-patterns, and I actually prefer the suggested method over the old one (I think the MENDER_FEATURES should be reserved for users to set, as much as possible). So as far as I’m concerned we can include these fixes right away.
But this is not a general promise to maintain compatibility between unrelated layers. That would require testing on a different level than we do now, and we may encounter situations in the future where it is much harder to maintain compatibility.
But this is not a general promise to maintain compatibility between unrelated layers. That would require testing on a different level than we do now, and we may encounter situations in the future where it is much harder to maintain compatibility.
I’m happy to contribute for the target devices that I use.
This sort of compatibility is definitely best practice but it’s maybe not documented too well in the Yocto Project docs. It’s covered by the “common.test_signatures” check in the yocto-check-layer script (Yocto Project Mega-Manual) but that’s not terribly clear unless you understand how the recipe signature generation works. I’ll feed back upstream that this could be clearer.
