From: Paul Barker <paul@pbarker.dev>
To: Zk47T <zizuzacker@gmail.com>, openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/1] rm_work: fix recipe self-exclusion lost when RM_WORK_EXCLUDE is conditional
Date: Thu, 30 Jul 2026 14:46:09 +0100 [thread overview]
Message-ID: <65336158366f4c89deb371942df7058cbf1a14ca.camel@pbarker.dev> (raw)
In-Reply-To: <20260725143015.23804-2-zizuzacker@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2656 bytes --]
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
prev parent reply other threads:[~2026-07-30 13:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-25 14:30 [PATCH 0/1] rm_work: recipe self-exclusion vs conditional RM_WORK_EXCLUDE Zk47T
2026-07-25 14:30 ` [PATCH 1/1] rm_work: fix recipe self-exclusion lost when RM_WORK_EXCLUDE is conditional Zk47T
2026-07-30 13:46 ` Paul Barker [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=65336158366f4c89deb371942df7058cbf1a14ca.camel@pbarker.dev \
--to=paul@pbarker.dev \
--cc=openembedded-core@lists.openembedded.org \
--cc=zizuzacker@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.