Yocto rm_work: Know What Survives Before Investigating a Recipe

A successful recipe build leaves task logs but no
packages-split directory. That combination can be expected
with rm_work: retaining logs does not mean retaining the
files those logs describe. The practical decision is whether the
investigation needs recorded commands, package metadata, or the actual
intermediate tree.

This explanation follows Yocto Project 5.0.12 Scarthgap and its
corresponding Poky source revision. Examples are proposed configuration
and inspection steps, not executed builds or measured space savings.

Cleanup follows the
recipe’s task graph

The class
reference enables cleanup with INHERIT += "rm_work" in
local.conf. Its description of removal after package
generation is a useful overview; the release-pinned
implementation determines the exact ordering.

For a non-excluded recipe, inject_rm_work derives the
tasks preceding do_build and places do_rm_work
after those prerequisites but before do_build. Cleanup can
therefore occur while the wider image build continues. Waiting until the
final image completes before saving intermediate files can be too
late.

There are additional cleanup points: the class attaches functions to
do_image_complete and do_populate_sdk that
clear the recipe’s rootfs and sdk work
directories. Inspect these hooks when investigating an image or SDK; the
main do_rm_work task is not the only removal boundary.

Exclude the
recipe before the investigation build

For an invented recipe named sensor-agent, the
configuration example is RM_WORK_EXCLUDE += "sensor-agent".
The implementation compares entries with PN. Use the
effective recipe identity, including a native variant when relevant,
rather than assuming an output package such as
sensor-agent-dev identifies the recipe.

The exclusion prevents the automatic cleanup dependency from being
injected for that recipe, disables its image/SDK cleanup directory
flags, and is also checked inside do_rm_work. Set it before
starting the build whose intermediate files are required. Adding it
afterward does not recover deleted contents or prove that a subsequent
invocation will recreate every intermediate.

Distinguish
surviving evidence from removed work

The pinned class and directory
defaults establish several different lifetimes:

• Task records: RM_WORK_EXCLUDE_ITEMS
  defaults to temp; T normally points to
  ${WORKDIR}/temp. Logs and generated task scripts there
  survive this cleanup. That is not a guarantee against later cleaning,
  overwriting, or a customized retention setting.
• Intermediate contents: ordinary source/build
  directories under WORKDIR and packages-split
  are removed unless an applicable exclusion preserves them. Read the
  effective S and B; their location can differ
  between recipes.
• Package metadata: PKGDATA_DIR defaults
  to ${TMPDIR}/pkgdata/${MACHINE}, outside the recipe work
  directory. Its existence is separate from retention of package file
  contents.

Cleanup also removes or converts selected task stamps. A surviving
stamp is not evidence that its former working files still exist.

Select
the smallest evidence set that answers the question

For “which package contains this installed path?”, the package-query
guide provides oe-pkgdata-util find-path. It requires
metadata for packages already built. For “what bytes were assigned to
each split package?”, retain the producer recipe and inspect
packages-split, which do_package creates. A
metadata listing cannot substitute for those bytes.

Before changing retention, inspect
bitbake -e sensor-agent for PN,
WORKDIR, T, S, B,
and both exclusion variables. After the intended tasks run, check the
specific paths needed for the question. Existing logs alone do not
demonstrate that source or packaging evidence survived. Keep source
fixes outside the disposable work tree; recipe exclusion supplies
temporary access, not a backup or an undelete facility.