Yocto Package Formats: Understand Why Only the First PACKAGE_CLASSES Entry Builds the Rootfs
A build produces both RPM and IPK files, yet its rootfs task still invokes the RPM backend. Adding package_ipk did not switch the image builder because PACKAGE_CLASSES is an ordered list with two related effects: it enables package writers and selects one package type for assembling images and SDKs.
The distinction matters when diagnosing a rootfs dependency error or an unexpected packaging task. The presence of an output file in a deploy directory does not identify the backend that consumed packages for the image.
Read the first entry and the complete list
The PACKAGE_CLASSES reference specifies that the first entry controls image and SDK creation, while additional entries enable additional package formats. For the illustrative configuration PACKAGE_CLASSES = "package_rpm package_ipk", expect RPM-based assembly and both enabled writers. Reversing those entries selects IPK-based assembly while retaining both formats.
This is not a fallback sequence. A failure resolving an RPM dependency does not instruct the build to retry the same image with IPK. Nor does the second entry request a second root filesystem assembled with a different package manager.
Inspect the effective value with bitbake -e product-image, replacing the example target with the real image recipe. Read the assignment history if the final order differs from local.conf. A distribution configuration or another included assignment may explain the result. Diagnose the final datastore rather than the first matching text line in a layer.
Follow how the selection reaches the image
The examined default distribution setup adds PACKAGE_CLASSES to INHERIT. The IPK writer supplies IMAGE_PKGTYPE ?= "ipk"; the RPM writer supplies the corresponding rpm default. With the normal ordered inheritance, the first applicable assignment establishes the value.
The image class selects rootfs_${IMAGE_PKGTYPE}. The SDK base class uses that same backend selection. This connects the configuration order to actual assembly behavior rather than merely to package filename extensions.
Do not force IMAGE_PKGTYPE separately to conceal a conflicting class list. Its reference explicitly describes it as indirectly selected through PACKAGE_CLASSES. An unexplained manual override leaves two sources of intent and makes later distribution changes harder to interpret.
Identify the failing operation by its task
For IPK assembly, the examined rootfs backend adds native opkg tools and recursive dependencies on IPK package writing and package QA. That provides concrete inspection points: check the selected rootfs class, the task dependency graph and the failing task's log.
A do_package_write_rpm failure is a package-output failure. A do_rootfs failure during package selection belongs to image assembly. If RPM was deliberately retained as a secondary output, its writer can still matter to requested build targets even though the image uses IPK. Decide whether that extra deliverable is required before removing it to make a build pass.
Conversely, adding another writer cannot manufacture a package that was never split out or fix an unsatisfied dependency declaration. Check the package named by the backend diagnostic. Changing the container format is not a substitute for correcting package contents and relationships.
Separate build-time assembly from target tools
The image-feature reference assigns package tools and retained package-management data to the package-management feature. PACKAGE_CLASSES alone does not establish that a deployed device has the tools and database required for field package operations.
For a controlled configuration change, compare the final PACKAGE_CLASSES order and IMAGE_PKGTYPE first. Then examine which writer tasks are enabled, which backend appears in the rootfs log, and which target tools the selected image features request. These observations answer three separate questions without requiring a field-update experiment.
Keep the intended extra formats explicit. A useful multi-format build has a named consumer for each secondary output and one understood image-assembly backend. A directory containing several package suffixes, by itself, proves neither multiple image backends nor runtime package-management readiness.
