Bug 14870 - Dangling bbappend behaviour can lead to unexpected surprises (error vs warn)
Summary: Dangling bbappend behaviour can lead to unexpected surprises (error vs warn)
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: oe-core other (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: Medium+ normal
Target Milestone: 5.2
Assignee: Richard Purdie
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2022-08-04 10:25 UTC by Andrei Gherzan
Modified: 2025-03-24 09:51 UTC (History)
3 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Don't know

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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