Lesson

Package Feeds and Runtime Package Management

How Yocto package feeds, package indexes, and runtime package managers fit into deployed systems

Practical Yocto Project DevelopmentValidating and Operating a Yocto ProductLesson 24 of 26

Yocto images are built from packages, even when you mostly think in terms of a complete disk image.

The relationship is:

Recipe
  -> binary packages
  -> package repository/feed
  -> root filesystem/image

That package step is not optional background detail. A recipe installs files into ${D}, BitBake splits those files into binary packages, and the image is created by installing selected packages into a root filesystem. Earlier lessons covered that recipe/package/image distinction in more detail: Images and Packages and Recipes, Packages and Package Splitting.

This lesson looks at the next question: if Yocto already creates packages, when would you expose those packages to a running target?

Package Formats and `PACKAGE_CLASSES`

The package format is selected with PACKAGE_CLASSES.

Common choices are:

package_ipk: Produces IPK packages, commonly used with opkg. This is a lightweight choice often seen in embedded systems.
package_rpm: Produces RPM packages, commonly used with RPM or DNF tooling. RPM carries more metadata and can be attractive for larger systems.
package_deb: Produces DEB packages, commonly associated with dpkg/APT-style tooling.

A simple configuration might use:

PACKAGE_CLASSES ?= "package_ipk"

The first package class in PACKAGE_CLASSES is the one used for image generation. You may see projects generate more than one package format, but I would not start there unless the product has a real reason. Every extra output format is another thing to store, index, test, and explain later.

Build Feeds and Published Feeds

During a build, Yocto writes generated packages under tmp/deploy:

tmp/deploy/ipk/
tmp/deploy/rpm/
tmp/deploy/deb/

The exact directory depends on the selected package format. The image construction process uses packages from the build’s package feed area when creating the root filesystem.

That local build output is not automatically a production package feed.

A real package feed is a maintained repository that a running target can use. It has package files, current indexes, a stable URL or transport, access control if needed, a relationship to a product release, and usually some signing policy. Publishing tmp/deploy/ipk/ to a web server without deciding how it is versioned or supported is not an update strategy. It is a directory with ambitions.

After adding or changing packages, regenerate the package indexes:

bitbake package-index

Those indexes are what the runtime package manager reads when it decides which packages are available and which versions satisfy dependencies.

Package Management

Building packages is not the same as putting runtime package management into the image.

If a target should install or upgrade packages after boot, the image needs the package manager tools and package database:

IMAGE_FEATURES += "package-management"

Without that feature, Yocto may still emit binary packages during the build, but the running target is not prepared to manage them.

Feed locations can be built into the image with variables such as:

PACKAGE_FEED_URIS = "https://feeds.example.com/my-product/2.3"
PACKAGE_FEED_BASE_PATHS = "ipk"
PACKAGE_FEED_ARCHS = "all cortexa53 myboard"

The final URL layout is project-specific. The important idea is that the target needs to know where to find package indexes and package files, and the feed needs to match the image, architecture, package format, and release policy.

On an IPK-based target, the runtime flow looks like this:

opkg update
opkg install my-diagnostic-tool

For RPM-based images you may see DNF or RPM tooling. For DEB-based images you may see APT or dpkg-style tooling. The commands differ, but the shape is the same: update the local package index, then install or upgrade a package from a configured feed.

A Small Worked Example

Suppose the project has a recipe for an engineering diagnostic tool:

meta-my-software/
`-- recipes-support/
    `-- my-diagnostic-tool/
        `-- my-diagnostic-tool_1.0.bb

That recipe produces a package called my-diagnostic-tool. The production image does not include it:

# my-product-image.bb
IMAGE_INSTALL:append = " my-product-app"

The package still exists if the recipe has been built. With IPK packaging, it might appear under a path like:

tmp/deploy/ipk/cortexa53/my-diagnostic-tool_1.0-r0_cortexa53.ipk

If the product has a configured package feed and the target image includes runtime package management, that package can be published to the feed, indexed, and installed later:

opkg update
opkg install my-diagnostic-tool

The key point is that the package can exist without being in the original image. That is useful for development and servicing, but it also means the resulting device state depends on both the shipped image and the packages installed later.

Feed Signing

A package feed used by deployed devices should not just be “whatever the server happens to return today”.

At a conceptual level, signing lets the target verify that package repository metadata, and sometimes the packages themselves, came from a trusted source and were not modified in transit. Yocto has support for signed package feeds, with project configuration controlling keys and signing behaviour.

Do not treat signing as a last-minute switch. A useful signing policy includes key generation, key storage, target trust configuration, key rotation, and a way to recover if something goes wrong. That is product infrastructure, not a recipe snippet.

Product Update Architecture

Package management and product update architecture are related, but they are not the same thing.

Being able to install or upgrade individual packages does not automatically make package-by-package updates a suitable OTA strategy. It only proves that the target has a package manager and can talk to a feed.

Package-level updates have real risks:

devices can end up with combinations of package versions that were never validated together
configuration files may need migration
dependency changes can pull in more than the engineer expected
rollback is harder than reinstalling the previous package
updates are not automatically atomic
the device may lose a known-good complete system state

None of that means package feeds are bad. It means they need to match the product model. A lab device on a bench, an internal engineering unit, and a safety critical field product do not have the same update requirements.

Complete-image updates are often easier to reason about because the validated unit is the whole system image. The update system can say, “this device is now running image version 2.3.0”, rather than reconstructing state from a base image plus a history of package operations. Detailed A/B designs, RAUC, Mender, SWUpdate, OSTree, rollback policy, and secure boot belong in separate update-system training. The Yocto point here is simpler: know which artifacts you are producing, and do not confuse package installation with a complete product update design.

When Would I Use a Package Feed?

Package feeds are useful when the product or workflow genuinely benefits from installing packages after the image has been built.

Realistic cases include:

development images where engineers install tools without rebuilding the image
field diagnostics where a controlled support package is installed temporarily
internal engineering systems that remain connected to a trusted feed
controlled servicing where a small package update is validated and deployed deliberately
products intentionally designed around package-level updates

I would be more cautious for general production updates where the product is expected to remain in a small number of well-defined system states. In those cases, complete-image updates are usually easier to validate, document, roll back, and support.

The non-dogmatic answer is this: package feeds are a useful mechanism, not a product strategy by themselves. Use them when they make the system easier to operate and support. Avoid them when they make the deployed state harder to know.

Package Formats and PACKAGE_CLASSES