Bug 14870

Summary: Dangling bbappend behaviour can lead to unexpected surprises (error vs warn)
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Andrei Gherzan <andrei>
Component: oe-core otherAssignee: Richard Purdie <richard.purdie>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Medium+ CC: Martin.Jansa, randy.macleod, richard.purdie
Version: unspecified   
Target Milestone: 5.2   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Don't know

Description Andrei Gherzan 2022-08-04 10:25:37 UTC 
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
Comment 1 Martin Jansa 2022-08-04 10:31:10 UTC 
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).
Comment 2 Andrei Gherzan 2022-08-04 10:33:47 UTC 
@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.
Comment 3 Richard Purdie 2022-08-04 10:38:08 UTC 
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.
Comment 4 Martin Jansa 2022-08-04 11:00:23 UTC 
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).
Comment 5 Andrei Gherzan 2022-08-04 11:03:21 UTC 
> 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.
Comment 6 Richard Purdie 2024-08-07 16:31:22 UTC 
Proposal made to OE-Arch: https://lists.openembedded.org/g/openembedded-architecture/message/2029