[PATCH] cooker: Drop support for BB_DANGLINGAPPENDS_WARNONLY

[PATCH] cooker: Drop support for BB_DANGLINGAPPENDS_WARNONLY

[Richard Purdie]

DANGLINGAPPENDS_WARNONLY is a very poorly designed interface and
is commonly abused. The challenge is that once it is set, by any
layer, it applies everywhere.

Some layers rely on this to get notification they need to update
bbappend files and having the behaviour change from inclusion of an
antisocial layer is not good.

In addition, showing warnings as an accepted thing on the console
devalues them and trains the user to ignore them. I want to steer us
away from this mindset.

We could extend the functionality and make it apply only to certain
layers, or only to certain appends but then we've basically re-invented
BBMASK.

Given all the above, we should drop support for BB_DANGLINGAPPENDS_WARNONLY
and direct anyone with issues to BBMASK instead.

https://lists.openembedded.org/g/openembedded-architecture/message/2029

[YOCTO #14870]

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 .../bitbake-user-manual-ref-variables.rst            | 12 ------------
 lib/bb/cooker.py                                     |  8 +-------
 2 files changed, 1 insertion(+), 19 deletions(-)

diff --git a/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst b/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst
index f23fb7f2a7..6c5bab4d4d 100644
--- a/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst
+++ b/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst
@@ -127,18 +127,6 @@ overview of their function and contents.
       Contains the name of the currently running task. The name does not
       include the ``do_`` prefix.
 
-   :term:`BB_DANGLINGAPPENDS_WARNONLY`
-      Defines how BitBake handles situations where an append file
-      (``.bbappend``) has no corresponding recipe file (``.bb``). This
-      condition often occurs when layers get out of sync (e.g. ``oe-core``
-      bumps a recipe version and the old recipe no longer exists and the
-      other layer has not been updated to the new version of the recipe
-      yet).
-
-      The default fatal behavior is safest because it is the sane reaction
-      given something is out of sync. It is important to realize when your
-      changes are no longer being applied.
-
    :term:`BB_DEFAULT_TASK`
       The default task to use when none is specified (e.g. with the ``-c``
       command line option). The task name specified should not include the
diff --git a/lib/bb/cooker.py b/lib/bb/cooker.py
index d58c0f575c..a8e0a81dc9 100644
--- a/lib/bb/cooker.py
+++ b/lib/bb/cooker.py
@@ -957,13 +957,7 @@ class BBCooker:
                                                                         '\n  '.join(appends_without_recipes[mc])))
 
         if msgs:
-            msg = "\n".join(msgs)
-            warn_only = self.databuilder.mcdata[mc].getVar("BB_DANGLINGAPPENDS_WARNONLY", \
-                False) or "no"
-            if warn_only.lower() in ("1", "yes", "true"):
-                bb.warn(msg)
-            else:
-                bb.fatal(msg)
+            bb.fatal("\n".join(msgs))
 
     def handlePrefProviders(self):
 

Re: [PATCH] cooker: Drop support for BB_DANGLINGAPPENDS_WARNONLY

[Konrad Weihmann]

[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]

It might be poorly designed but it helps a lot in the following situation
We have poky or any other "lower" layer providing a recipe-x_1.2.3.
Then we have a layer on top doing a recipe-x_1.2.3.bbappend (to applying backported patches or configuration options or anything version specific).
Now there is an update to the lower to version 1.2.4.
With the removal we get a failing build, with the WARN only we get just a warning, version 1.2.4 is picked.
Final decision if the build is good can be done in testing and/or post inspection.
With the functionality removed I would need to add a patch to the upper layer with a BBMASK
which then in any CI system I know would build with the older lower layer, basically removing the
entire append (which can't be right).
Alternative would be to schedule two changes at the same time (updated lower layer and patched upper layer).
To be honest I've not seen an automated CI system that works like that, leaving it all with
manual assembly of the inputs - requiring a ton of extra work.

Another alternative would be to loosen the bbappend mask to cover all version of the base recipe, but
that makes it impossible (without huge efforts) to apply patches for just a single version.
All in all the functionality might have been poorly designed but very helpful and
I don't see BBMASK as an equivalent replacement.

my 2 cents

[-- Attachment #2: Type: text/html, Size: 1557 bytes --]