14870 2022-08-04 10:25:37 +0000 Dangling bbappend behaviour can lead to unexpected surprises (error vs warn) 2025-03-24 09:51:41 +0000 1 1 7 Build System, Metadata & Runtime OE-Core oe-core other unspecified x86 Multiple RESOLVED FIXED Medium+ normal 5.2 1 andrei richard.purdie Martin.Jansa randy.macleod richard.purdie --- --- Don't know oldest_to_newest 93715 0 andrei 2022-08-04 10:25:37 +0000 BB_DANGLINGAPPENDS_WARNONLY handles how bitbake behaves when at least a dangling bbappend is found. By default, when nothing defines it, bitbake will error out in such a case. This is usually the behaviour that a lot of projects are relying on when handling their bbappends (so they are forced to handle forward-porting or dropping with layer upgrades). Sadly this is just way too easy to be injected through layer upgrades that can affect this behaviour unexpectedly. For example: 1. a layer starting to define BB_DANGLINGAPPENDS_WARNONLY=1 in layer.conf 2. a distro that does the same when the downstream inherits it or uses it directly 93716 1 Martin.Jansa 2022-08-04 10:31:10 +0000 I think a good solution would be to make it more like BBMASK, so that it would list only the .bbappends which might be dangling? That way such layer can explicitly list only the bbappends which are allowed to be dangling (even in layer.conf) without affecting any other layers included in the build. And also it would still allow this variable to be used e.g. from local.conf to temporarily unblock parsing some layer with dangling bbappend without modifying that layer (BBMASK could be used instead, if the bbappend is always dangling). 93717 2 andrei 2022-08-04 10:33:47 +0000 @martin Wouldn't this just duplicate BBMASK (or at least be a subset of it)? I am tempted to say that my vote is to drop it altogether - drop BB_DANGLINGAPPENDS_WARNONLY. 93718 3 richard.purdie 2022-08-04 10:38:08 +0000 Layers being able to change behaviours of other layers is a poor API and I'm tempted to remove this and refer people to BBMASK if they need it. 93719 4 Martin.Jansa 2022-08-04 11:00:23 +0000 Yes, it would be very similar to BBMASK, but the difference would be that it won't be _always_ masked, only when the recipe doesn't exist (while triggering the warning) and applied when it can be applied. But as said on IRC I don't use BB_DANGLINGAPPENDS_WARNONLY, someone with valid use-case for it, should comment on this (before they start complaining after it's dropped completely). 93720 5 andrei 2022-08-04 11:03:21 +0000 > But as said on IRC I don't use BB_DANGLINGAPPENDS_WARNONLY, someone with > valid use-case for it, should comment on this (before they start complaining > after it's dropped completely). Totally agree - same here. 99508 6 richard.purdie 2024-08-07 16:31:22 +0000 Proposal made to OE-Arch: https://lists.openembedded.org/g/openembedded-architecture/message/2029 101473 7 richard.purdie 2025-03-24 09:51:41 +0000 https://git.yoctoproject.org/poky/commit/?id=282cc1ea929f2dc43c095c0029c3b3974bb40566