On Sat, 2026-07-25 at 21:30 +0700, Zk47T wrote:
> A recipe keeps its WORKDIR by adding itself to the exclusion list:
> 
>     RM_WORK_EXCLUDE += "${PN}"
> 
> += is evaluated at parse time against the unoverridden variable, so it
> appends to the base value. As soon as configuration sets an override such
> as RM_WORK_EXCLUDE:qemuarm64, that override takes precedence at lookup
> time and the recipe's own entry is hidden from both the python guard in
> inject_rm_work() and the shell guard in do_rm_work.
> 
> The WORKDIR is then removed even though it was meant to be kept. For
> gcc-source that is the shared source tree the other gcc recipes build
> from, 1.4G here, so the next build needing it fetches, unpacks and
> patches it again, and anything still using it while do_rm_work runs can
> fail outright. The report has gcc-source do_patch failing.
> 
> Use :append, which is applied on top of whichever override wins. With no
> override involved both operators produce the same string, so task
> signatures and sstate are unaffected.
> 
> gcc-source used deltask, which had no such failure mode, until
> 1f2a3cdadac1 switched it to this idiom; the other three recipes adopted
> the idiom afterwards.
> 
> Fixes: 1f2a3cdadac1 ("gcc-source.inc: cleanly disable do_rm_work")
> [YOCTO #16157]
> 
> Signed-off-by: Nguyen Minh Tien <zizuzacker@gmail.com>

Hi,

We try to avoid replacing += with append in recipes unless we really
have to.

The difficulty here is that RM_WORK_EXCLUDE has two use cases:
- It can be set in local.conf or similar to list recipes you are
  debugging/developing and need to keep work directories for.
- It can be set in a recipe to indicate that removing the work directory
  can break subsequent tasks.

Discussing this on the patch review call, we had the idea that we could
split these use cases into two different variables so we're no longer
worried about :append in conf files overwriting += in a recipe. I
suggest we keep RM_WORK_EXCLUDE for the conf file use case and add a new
variable that can be set in a recipe to self-exclude. Perhaps something
like `NO_RM_WORK = "1"`?

Some discussion may be needed to find a variable name people are happy
with but the implementation should be straightforward. do_rm_work() can
check both the RM_WORK_EXCLUDE and the new variable.

So, please send a v2. And make sure you use the AI-Generated tag in the
commit message if it is needed as per our contribution guidelines [1].

[1]: https://docs.yoctoproject.org/contributor-guide/submit-changes.html#acceptance-of-ai-generated-code

Best regards,

-- 
Paul Barker