Yocto Dynamic Packages: Distinguish a Provider Promise from an Emitted Plugin

An image depends on sensor-plugin-wave, and BitBake accepts the provider relationship. Later, root filesystem creation cannot find that package. The recipe advertises a matching dynamic package family, but its installed outputs never produced the requested member.

This failure has two distinct checkpoints: metadata can promise that a recipe provides a name before packaging has discovered which plugin files actually exist. Diagnose the gap between those checkpoints rather than adding increasingly broad provider patterns.

Keep the promise narrower than the namespace

The PACKAGES_DYNAMIC definition explicitly distinguishes a provider promise from a produced package. An unresolved hard runtime dependency can consequently fail during do_rootfs, even though BitBake previously found a plausible providing recipe.

For an illustrative plugin family, PACKAGES_DYNAMIC += "^sensor-plugin-.*" advertises names beginning with sensor-plugin-. It neither enables the upstream wave plugin nor creates a binary archive for it. A pattern covering every sensor-related package would make unrelated missing names look temporarily satisfiable.

Write down the exact requested name and the producing recipe before inspecting files. If the name is misspelled or belongs to another recipe, correct that relationship first. Expanding a regex cannot repair a dependency on a nonexistent interface.

Follow the split function's actual inputs

The optional-module packaging guide describes calling do_split_packages from a packaging hook. Its arguments connect a directory, filename regex and output-name pattern.

Consider the illustrative call do_split_packages(d, '${libdir}/sensor/plugins', r'^mod_(.*)\.so$', 'sensor-plugin-%s', 'Sensor plugin %s'). A regular file named mod_wave.so supplies the captured text wave, which yields sensor-plugin-wave. The example is a function call inside an appropriate Python packaging hook, not a complete standalone recipe.

The helper also sets file and description metadata. By default it adds a dependency on the main recipe package; pass extra_depends='' only when that dependency is genuinely unnecessary. A plugin requiring its host application should not lose that relationship merely to silence a resolver error.

Separate absent roots, unmatched files and missing hooks

The examined package class implementation searches beneath PKGD plus the supplied target root. If that directory is absent, it returns an empty result. Its default search is nonrecursive, and directories or symbolic links are not eligible unless the corresponding options are enabled.

Inspect the actual directory used by the hook. A plugin installed under an architecture-specific subdirectory will not be found by a nonrecursive search of its parent. A symlink named mod_wave.so pointing to another file also differs from an eligible regular file under the default settings.

The implementation matches the regex, normalizes the captured module text into a legal package name, and adds the resulting name to PACKAGES. Therefore compare the emitted package name with the requested dependency instead of assuming punctuation survives unchanged.

If eligible matching files exist but no dynamic package appears, check that the hook participates in packaging before file population. Adding a helper definition without invoking it leaves the provider promise disconnected from output discovery.

Decide whether absence is a valid configuration

A disabled upstream feature may legitimately omit a plugin. If the consuming application requires wave support, keep the hard dependency and correct the feature configuration or split logic. An empty placeholder package would satisfy the name while still omitting the required implementation.

If the consumer remains useful without that plugin, the RRECOMMENDS contract allows a recommended package not to be produced, provided a recipe advertises it through the documented provider mechanisms. This is a product behavior decision, not a universal recovery switch.

Check one configuration that emits mod_wave.so and one that intentionally omits it. The first should produce the expected package with the plugin payload; the second should either reject a mandatory consumer or build a deliberately reduced optional configuration. Those outcomes make the dynamic promise testable without pretending that every advertised family member always exists.