Yocto Feature Backfill: Explain a Distro Feature That Returns After an Upgrade
A distribution configuration omits a feature, but the final recipe metadata contains it after a Yocto upgrade. Removing a package from the image does not explain why the feature returned. Before chasing every recipe option, inspect the backfill mechanism that preserves historical defaults when new feature controls are introduced.
Backfill is an addition policy. Its considered list blocks selected automatic additions; it is not a general instruction to remove a feature from every possible source.
Read the three lists together
The feature-backfilling guide describes paired distro and machine controls. For a distro investigation, inspect the effective DISTRO_FEATURES, DISTRO_FEATURES_BACKFILL and DISTRO_FEATURES_BACKFILL_CONSIDERED values in the affected recipe's environment.
The backfill list identifies features supplied automatically for compatibility. The considered list records opt-outs from those additions. The variable reference describes this opt-out relationship; the upstream backfill list itself is not intended as the distribution maintainer's customization interface.
Consider an illustrative feature named demo-audio. If it is absent from the distro's existing features, present in backfill and absent from considered, it is eligible to be added. If it is also in considered, backfill should not add it. These are hypothetical list entries, not claims about a release's current default audio configuration.
Considered does not erase an explicit feature
The examined features_backfill implementation collects a backfill entry only when it is absent from both the existing feature list and the considered list. It then appends the collected entries. There is no removal step in this function.
That distinction explains a common failed repair. Adding demo-audio to considered will not remove an explicit DISTRO_FEATURES += " demo-audio" elsewhere. If the final value still includes it, inspect assignment history and other feature contributors rather than assuming the opt-out variable is ignored.
Conversely, leaving a feature out of an explicitly written distro list is not necessarily an opt-out from backfill. A maintainer can specify a short feature list and still receive the compatibility additions. The considered list is the mechanism intended to express that particular decision.
Inspect a recipe context after backfill has run
The examined base class invokes the backfill helper for distro and machine features during recipe metadata processing. A quick glance at the distro configuration file is therefore not the final answer about what a recipe sees.
Use bitbake -e sensor-agent, substituting a representative affected recipe, and inspect the expanded lists and their history. Compare the old and new metadata revisions when investigating an upgrade. Identify whether the backfill list changed, an explicit assignment changed, or an inherited configuration started contributing the feature.
For a real backfilled feature intentionally excluded by product policy, add its actual name to DISTRO_FEATURES_BACKFILL_CONSIDERED in the maintained distro configuration. Preserve other considered entries. Then re-evaluate the same recipe instead of checking only the text of the edited file.
Keep feature policy separate from recipe consumption
After the final feature list is understood, trace the affected recipe's response. The DISTRO_FEATURES reference cautions that a feature's presence does not by itself enable every package's support; recipe mechanisms such as PACKAGECONFIG must consume it.
If the feature is absent but a component remains enabled, inspect an explicit recipe option or dependency. If the feature is present but the component is disabled, inspect whether that recipe follows the feature at all. Changing backfill cannot repair a recipe that never consults the feature.
Machine backfill has its own paired variables. Do not put a hardware capability's opt-out into the distro considered list and expect it to control MACHINE_FEATURES.
For the upgrade review, the useful result is a small explanation: which automatic addition changed the final list, whether product policy accepts it, and which recipe consumers change as a consequence. This keeps a compatibility mechanism from becoming an unexplained source of configuration drift.
