Yocto Buildhistory: Separate Installed Package Changes from Task Rebuild Noise

A build reruns hundreds of tasks, yet the installed package set is unchanged. Another build reuses many tasks but introduces a new library into the image. Task activity and delivered content answer different questions.

Yocto buildhistory is useful when the question is what changed in the packages or root filesystem. Use it to narrow a content regression before investigating the build scheduler or assuming that a longer build produced a larger image.

Capture comparable output histories

The Yocto 5.0.12 buildhistory guide enables collection with INHERIT += "buildhistory"; BUILDHISTORY_COMMIT = "1" keeps changes in a local Git repository. The usual directory is beneath the build directory, but inspect BUILDHISTORY_DIR rather than assuming a fixed location.

Choose a baseline and candidate for the same intended image configuration. Before interpreting a difference, check whether the machine, image recipe or distribution policy also changed. Comparing two unrelated images can produce accurate file differences with little diagnostic value.

Verify collection scope using BUILDHISTORY_FEATURES. Image and package collection provide different views. If only image information was enabled, the absence of a package-level record is not proof that the package stayed unchanged.

Begin with names, then versions and payloads

Compare installed-package-names.txt first to find additions and removals. If the names match, inspect installed-packages.txt and the package records for changed versions or revisions. A stable package name does not establish stable contents.

The guide also documents FILELIST as the actual packaged files and PKGSIZE as their total size in bytes. FILES is the packaging selection expression, which is a different kind of information. An unchanged wildcard can select a newly generated file, so comparing only the expression can miss growth.

For an illustrative addition of libtelemetry, ask which installed package gained the dependency and whether the library supports an intentionally enabled feature. Follow the dependency change before deleting the new library. If the package set stayed constant but sensor-ui grew, inspect its file list instead of searching for a nonexistent new package.

Read size and file records according to their meaning

The examined scarthgap buildhistory implementation writes root-filesystem listings with permissions, ownership, size and symlink targets. It deliberately excludes timestamps from that listing. These records can reveal a permission or link-target regression even when the package list is unchanged.

The same implementation derives IMAGESIZE using du -ks on the constructed root filesystem. That is not the byte length of a compressed deployment archive or the capacity of a Wic partition. Compare the relevant final artifact separately when the actual problem is download size or storage allocation.

Likewise, a file list is not a byte-for-byte content proof. Two configuration files can have the same pathname and length but different values. BUILDHISTORY_IMAGE_FILES can copy selected image files into history for content comparison. Missing paths do not produce an error, so confirm that the expected file was actually captured.

Use the right view for the remaining question

The guide's buildhistory-diff utility provides a human-readable summary of potentially significant changes. Treat that summary as a triage view; inspect the underlying Git diff and relevant records when a particular small change matters to the product.

If the content question is resolved but build duration remains unexplained, use buildstats, which records task elapsed time, CPU usage and I/O. A buildhistory package-size difference does not identify a slow compiler task, and task timings do not identify an accidentally installed file.

A practical investigation should end with a concrete explanation: a new dependency expanded the package set, an existing package acquired files, an image-stage operation changed filesystem metadata, or the measured deployment format changed independently. That explanation makes the next fix specific without mistaking rebuild activity for a delivered-content regression.