Yocto Package Architecture: Avoid Reusing Machine-Specific Output as Architecture-Independent

A package contains only text files, so its recipe inherits allarch. Later, a second board receives a configuration generated for the first board, or alternating machine builds repeatedly rerun packaging. The absence of ELF binaries does not establish that the recipe is architecture-independent.

The relevant boundary includes generated content, package dependencies and the configuration used to produce them. In Yocto Project 5.0.12, allarch is a build-policy choice with consequences beyond the architecture label printed on a package.

Classify the output by what can change

The PACKAGE_ARCH reference distinguishes the normal target tune architecture from machine-specific output. A recipe producing board-specific packages should use PACKAGE_ARCH = "${MACHINE_ARCH}" rather than claiming that the result applies to every machine.

Consider an illustrative sensor-layout recipe. It installs a text file describing connector assignments. If every supported board uses identical contents and dependencies, the file may be a candidate for architecture-independent packaging. If a generation step substitutes ${MACHINE} or selects a board's wiring map, the text format does not make the result universal.

Compare the inputs that select those contents: overrides, source files, configure arguments and generation scripts. The new-recipe architecture guidance specifically calls out machine-specific configuration and patches. A package can therefore need machine scope without containing machine instructions.

Check dependencies before choosing allarch

The allarch class documentation warns against using it for recipes whose runtime dependencies depend on tunings through RDEPENDS and TUNE_PKGARCH, even when their own payload is architecture-independent. In that situation, package-writing task signatures can differ between tunings and cause unnecessary rebuilds.

Inspect the effective runtime dependencies of each output package, not only the recipe's source text. A script may be identical across machines while its package relationship has become tuning-specific. That is a different failure from generated board data being different, and comparing file hashes alone will miss it.

Do not respond to repeated packaging by deleting the dependency that makes the program runnable. First determine whether the recipe should use normal target architecture handling, machine-specific handling, or a separation between reusable data and a machine-dependent component.

Understand what the class changes

The examined scarthgap allarch implementation removes normal target-build assumptions when the package architecture is all. It inhibits default compiler and C-library dependencies, disables shared-library processing, and changes debug-splitting behavior. It also substitutes generic target metadata for this context.

Consequently, adding allarch to a compiled program is not a harmless way to improve cache reuse. Conversely, changing only a package filename after the build cannot repair an inappropriate compilation context. Review inheritance and the effective variables together when correcting the recipe.

Compare two configurations at the package boundary

Use two supported machines that expose the disputed difference. For the same recipe revision, inspect bitbake -e sensor-layout in each configured build and compare PACKAGE_ARCH, MACHINE_ARCH, TUNE_PKGARCH, relevant overrides and package-specific dependencies. Read assignment history when a layer changes the expected value.

Then compare extracted package payloads and package metadata, keeping the package backend's architecture naming in view. Focus on the files that should remain identical and the fields that are intentionally different. A matching source archive is insufficient if installation generates board-specific data afterward.

If one recipe mixes a common schema with a board mapping, separate recipes can make the architecture boundary clearer: the schema can remain invariant while the mapping carries machine scope. This is a design option, not a requirement to split every configuration package.

Finally, rebuild both configurations after the correction and inspect the newly produced packages. Existing deployed files do not change merely because metadata has been fixed. The useful outcome is an architecture declaration that matches the payload and dependency contract, rather than a universal label chosen solely because the files look portable.