Fix Yocto “RDEPENDS but Not a Build Dependency”

This warning is less about spelling and more about timing. By packaging time, OpenEmbedded knows that one output package requires another—but the dependency was not explicit early enough for the build graph to guarantee the provider package would exist. The safe fix depends on why that runtime edge exists.

The warning in plain English

WARNING: QA Issue: package-a rdepends on package-b,
but it isn't a build dependency? [build-deps]

What the message proves—and what it does not

• package-a contains runtime metadata requiring package-b.

• The build system did not see an adequate explicit relationship early enough to guarantee that dependency through the task graph.

• The warning does not prove that package-b is absent from the current image or feed; cached output can hide missing metadata.

• It does not tell you whether the correct edit is RDEPENDS, DEPENDS, package splitting, or removal of an accidental dependency. You must trace the cause.

Quick decision flow

Why does package-a need package-b?
│
├─ Runs a program / loads data / needs service only on target
│    └─ explicit RDEPENDS:<owning-package> += "package-b"
│
├─ Compiles/links/generates using provider artifacts
│    └─ DEPENDS += "provider-recipe"
│       (runtime dependency may be auto-detected or also explicit)
│
├─ Dependency caused by a misplaced file or bad shebang/link
│    └─ fix FILES/install/shebang/linkage; do not encode the mistake
│
└─ Dependency is conditional
     └─ gate it with the same PACKAGECONFIG/feature/override condition

The two namespaces matter

• DEPENDS contains recipe or PROVIDES names. Do not put foo-dev or another output package name there.

• RDEPENDS:<package> contains package names as they appear in PACKAGES, before backend renaming through PKG.

• ${PN} is often both the recipe and main package name, which makes incorrect metadata appear plausible until a split package or renamed provider is involved.

• Use resolved package data and provider information rather than inferring names from an RPM/DEB filename.

Why automatic dependencies can trigger build-deps

During do_package, OpenEmbedded scans installed output and can add runtime dependencies—for example from shared-library linkage or script interpreters. That discovery is valuable, but it happens late. If nothing earlier made the provider recipe part of the graph, package output may depend on something the build was never required to produce.

• A linked library normally implies the provider’s headers/library were needed during the build, so an appropriate DEPENDS relationship should usually exist.

• A script invoking an interpreter may need only a runtime package; explicit RDEPENDS makes that requirement visible before package analysis.

• A plugin loaded dynamically may evade automatic ELF dependency detection and need explicit runtime metadata.

• Files accidentally assigned to the wrong output package can create a real but unwanted dependency; fix the split rather than papering over it.

Fix 1: an intentional runtime-only dependency

RDEPENDS:${PN} += "package-b"

What this declaration changes

• The left side identifies which output package owns the dependency; use ${PN}-tools, ${PN}-ptest, or another split when that is the true consumer.

• The right side is the runtime package name, not necessarily the provider recipe name.

• += appends without discarding dependencies supplied by classes, defaults, or other metadata.

• The generated package manager metadata will require package-b, and BitBake adds the related package-write task dependency.

• For older supported branches, underscore overrides such as RDEPENDS_${PN} may be required; use the syntax of the branch, not a mixed style.

Fix 2: a real build-time dependency

DEPENDS += "provider-recipe"

Why DEPENDS is different

• DEPENDS causes the provider’s sysroot task to be available before the consumer configures, through OpenEmbedded’s task dependencies.

• All relevant development artifacts emitted by the provider recipe can enter the consumer’s recipe-specific sysroot; naming package-b-dev in DEPENDS is incorrect.

• DEPENDS alone does not semantically declare that an output package must be installed at runtime, although shared-library scanning often generates that runtime edge automatically.

• If the program also intentionally requires a non-auto-detected runtime package, declare the appropriately scoped RDEPENDS as well.

Fix 3: condition both sides consistently

PACKAGECONFIG[feature-b] = "--enable-feature-b,--disable-feature-b,provider-recipe,package-b"
PACKAGECONFIG ??= "feature-b"

What PACKAGECONFIG expresses

• The four comma-separated fields are enable arguments, disable arguments, build dependencies, and runtime dependencies; later optional fields can express runtime recommendations and conflicts.

• When feature-b is enabled, provider-recipe enters DEPENDS and package-b enters the relevant runtime dependency calculation.

• When disabled, both edges disappear with the feature instead of leaving unconditional packages in minimal images.

• Confirm the inherited build class actually consumes the configure arguments; metadata alone cannot repair an upstream build system that ignores them.

When both DEPENDS and RDEPENDS are justified

• The recipe consumes provider headers/libraries during compilation and the resulting package needs a runtime component that automatic scanning cannot identify.

• A code generator or native tool is required during the build while a distinct target package supplies runtime data or a service.

• The relationship is feature-gated, and both graph edges must follow the same feature selection.

• Keep the recipe/provider name on the build side and the exact output package name on the runtime side; matching strings are incidental, not a rule.

Identify the package and provider recipe

$ oe-pkgdata-util lookup-recipe package-b
oe-pkgdata-util list-pkgs provider-recipe
bitbake-layers show-recipes provider-recipe

Read these results carefully

• lookup-recipe maps an emitted package back to its recipe using existing pkgdata; build/package the provider first if pkgdata is unavailable.

• list-pkgs shows packages emitted by the recipe and helps avoid confusing ${PN} with a split output.

• show-recipes reveals available providers/versions and layer selection; it does not prove which package owns a particular file.

• If virtual providers are involved, inspect PROVIDES, RPROVIDES, and preferred-provider configuration in the resolved environment.

Trace why the dependency appeared

$ oe-pkgdata-util read-value RDEPENDS package-a
oe-pkgdata-util list-pkg-files package-a
bitbake -e consumer-recipe > consumer-recipe.env
rg -n '^(DEPENDS|RDEPENDS|PACKAGES|FILES)' consumer-recipe.env

Evidence to collect before editing

• The resolved RDEPENDS value tells you what packaging emitted, while variable history in bitbake -e shows where explicit metadata was assigned.

• The file list can expose a script, binary, plugin, or misplaced file responsible for the relationship.

• Expanded environments can contain internal URLs and secrets. Store them securely and redact before sharing.

• Automatic dependency details also live in package work directories and do_package logs; exact paths vary by release and tune.

Verify with a clean package-data path

$ bitbake -C package consumer-recipe
bitbake consumer-recipe
oe-pkgdata-util read-value RDEPENDS package-a
bitbake target-image

Why verification goes beyond one recipe

• -C package invalidates package processing and runs the recipe’s normal target, reconsidering downstream packaging work without deleting shared caches.

• The explicit recipe build confirms the package provider graph and reruns QA under the corrected metadata.

• Reading pkgdata verifies the stored runtime edge and its exact package spelling.

• Building the target image proves the package manager can resolve the dependency in the actual product configuration.

• This command group changes build outputs and may consume significant time/disk, but it does not install anything on the host or target.

Common wrong fixes

• Put `package-b` in IMAGE_INSTALL: this can hide the warning’s consequence in one image while leaving package metadata/build ordering wrong for feeds, SDKs, and other images.

• Put `package-b-dev` in DEPENDS: build dependencies use recipe/provider names, not split package names.

• Add the dependency to bare `RDEPENDS`: always scope runtime relationships to the actual output package.

• Use `=` instead of `+=`: overwriting can silently remove dependencies supplied elsewhere.

• Disable `[build-deps]` through QA controls: suppression removes the signal, not the incomplete graph. Reserve narrow suppression for a documented false positive after proving it.

• Clean everything: deleting tmp, downloads, or shared sstate destroys evidence and may make a cached-ordering problem harder to reproduce.

Diagnosis table

• ELF binary links to package-b library: identify the library provider recipe; add it to DEPENDS, then confirm automatic runtime dependency and package split.

• Shell/Python/Perl script invokes runtime tool: add the package providing that executable to the consuming split package’s RDEPENDS.

• Optional plugin or feature: use PACKAGECONFIG or matching feature conditions for both build and runtime edges.

• Dependency points to `-dev`: inspect misplaced unversioned .so or development files and correct FILES:*; do not usually install -dev on production targets.

• Wrong package name after Debian renaming: use the name from PACKAGES/pkgdata for RDEPENDS, not the final backend-renamed filename.

• Warning persists after edit: confirm the append applies, override syntax matches the release, provider is selected, packaging was rerun, and the dependency belongs to the package you changed.

A durable review checklist

1. Copy the exact warning and record recipe, machine, distro, layers, and release.

1. Map both package names to provider recipes and inspect their package splits.

1. Find the file or explicit metadata that created the runtime edge.

1. Classify it as build-time, runtime-only, conditional, or accidental.

1. Edit the owning recipe/append using the correct namespace and package override.

1. Rerun package processing and QA, inspect pkgdata, and build the target image/feed.

1. Document why the relationship exists so a future cleanup does not remove it as “redundant.”

Related Yocto guides

• Understand when each task runs in the BitBake build process guide.

• Debug package ownership with Yocto package data and oe-pkgdata-util.

• Review conditional metadata in PACKAGECONFIG for Yocto recipes.

Primary references

• The Yocto Project QA message reference defines the [build-deps] condition and recommended explicit relationship.

• The Yocto Project DEPENDS reference explains recipe/provider names and recipe-specific sysroot ordering.

• The Yocto Project RDEPENDS reference explains package-scoped runtime dependencies and package-write task edges.