# Adding the meta-mender-raspberrypi layer prevents building for non-Raspberry Pi targets or disabling \`mender-image\` feature
**URL:** https://hub.mender.io/t/adding-the-meta-mender-raspberrypi-layer-prevents-building-for-non-raspberry-pi-targets-or-disabling-mender-image-feature/809
**Category:** General Discussions
**Tags:** yocto
**Created:** [July 10, 2019, 8:32am UTC](https://hub.mender.io/t/adding-the-meta-mender-raspberrypi-layer-prevents-building-for-non-raspberry-pi-targets-or-disabling-mender-image-feature/809 "2019-07-10T08:32:32Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@pbrkr](https://hub.mender.io/u/pbrkr)
#### Post date: [July 10, 2019, 8:32am UTC](https://hub.mender.io/t/adding-the-meta-mender-raspberrypi-layer-prevents-building-for-non-raspberry-pi-targets-or-disabling-mender-image-feature/809/1 "2019-07-10T08:32:32Z")
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.
---
### Author:  [@mirzak](https://hub.mender.io/u/mirzak)
#### Post date: [July 10, 2019, 9:02am UTC](https://hub.mender.io/t/adding-the-meta-mender-raspberrypi-layer-prevents-building-for-non-raspberry-pi-targets-or-disabling-mender-image-feature/809/2 "2019-07-10T09:02:38Z")
Hi @pbrkr
> [@pbrkr](#):
>
> 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 😃
---
### Author:  [@pbrkr](https://hub.mender.io/u/pbrkr)
#### Post date: [July 10, 2019, 10:09am UTC](https://hub.mender.io/t/adding-the-meta-mender-raspberrypi-layer-prevents-building-for-non-raspberry-pi-targets-or-disabling-mender-image-feature/809/3 "2019-07-10T10:09:46Z")
> > 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](http://Mender.io) integration long before that.
---
### Author:  [@pbrkr](https://hub.mender.io/u/pbrkr)
#### Post date: [July 10, 2019, 10:24am UTC](https://hub.mender.io/t/adding-the-meta-mender-raspberrypi-layer-prevents-building-for-non-raspberry-pi-targets-or-disabling-mender-image-feature/809/4 "2019-07-10T10:24:27Z")
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.
>
>
---
### Author:  [@mirzak](https://hub.mender.io/u/mirzak)
#### Post date: [July 10, 2019, 10:55am UTC](https://hub.mender.io/t/adding-the-meta-mender-raspberrypi-layer-prevents-building-for-non-raspberry-pi-targets-or-disabling-mender-image-feature/809/5 "2019-07-10T10:55:53Z")
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?
```auto
MENDER_FEATURES_DISABLE_append_rpi = " mender-grub mender-image-uefi"
MENDER_FEATURES_ENABLE_append_rpi = " mender-uboot mender-image-sd"
```
---
### Author:  [@mirzak](https://hub.mender.io/u/mirzak)
#### Post date: [July 10, 2019, 11:06am UTC](https://hub.mender.io/t/adding-the-meta-mender-raspberrypi-layer-prevents-building-for-non-raspberry-pi-targets-or-disabling-mender-image-feature/809/6 "2019-07-10T11:06:51Z")
> 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](https://github.com/Angstrom-distribution/angstrom-manifest/blob/master/default.xml) 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…
Reading trough [_Yocto Project Board Support Package (BSP) Developer’s Guide_](https://www.yoctoproject.org/docs/2.6/bsp-guide/bsp-guide.html), it does not mention anything about this nor do their [examples](https://www.yoctoproject.org/docs/2.6/bsp-guide/bsp-guide.html#customizing-a-recipe-for-a-bsp) “comply” to the “way Yocto Project BSP layers should work”
We have a lot more integration layers in [meta-mender-community](https://github.com/mendersoftware/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.io](http://mender.io/)integration long before that.
I did not mean to hold any changes until then, and just consider this easier to discuss in person.
---
### Author:  [@kacf](https://hub.mender.io/u/kacf)
#### Post date: [July 11, 2019, 6:27am UTC](https://hub.mender.io/t/adding-the-meta-mender-raspberrypi-layer-prevents-building-for-non-raspberry-pi-targets-or-disabling-mender-image-feature/809/7 "2019-07-11T06:27:16Z")
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.
---
### Author:  [@pbrkr](https://hub.mender.io/u/pbrkr)
#### Post date: [July 12, 2019, 3:12pm UTC](https://hub.mender.io/t/adding-the-meta-mender-raspberrypi-layer-prevents-building-for-non-raspberry-pi-targets-or-disabling-mender-image-feature/809/8 "2019-07-12T15:12:23Z")
> 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](https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#yocto-check-layer-script)) 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.