Yocto PR Service: Keep Feed Revisions Monotonic Across Multiple Builders

Two build workers publish packages to the same development feed. Both start with recipe revision r0, and both rebuild after different source or metadata changes. The resulting files can contain new bytes while their package version ordering fails to express a reliable upgrade path for installed devices.

BitBake's decision to rebuild and a target package manager's decision to upgrade are separate mechanisms. A task signature can change without a manually maintained package revision changing alongside it.

Inspect the binary package version first

The package-version guide distinguishes recipe version and revision from the resulting binary package identity. Inspect the actual package metadata presented to the target, including epoch where used, rather than relying on a recipe filename or build timestamp.

For an illustrative unchanged upstream version, two different builds might both be labeled 2.1-r0 if revision policy does not distinguish them. An ordinary upgrade comparison cannot use an unpublished task hash as an ordering instruction.

Reproduce the symptom by recording the installed package's version and the candidate feed version. If the candidate is not considered newer, establish whether revision generation is absent, inconsistent across workers, or based on a reset history. Do not begin by forcing reinstall; that bypasses the ordering question being diagnosed.

Coordinate a single revision history

The PR Service documentation describes automatically generated revision suffixes, such as additions to an existing r0. For a single builder, PRSERV_HOST = "localhost:0" starts a local service managed by BitBake.

That local setting is not a shared history across separate machines. For multiple builders contributing to one feed, the documented arrangement uses one service to which the builders connect. The PRSERV_HOST reference identifies the configured host and port.

Inventory the effective endpoint on every contributing worker. A copied CI configuration containing localhost can unintentionally create independent histories that each look correct in isolation. Workers producing unrelated private experiments should not silently become feed publishers merely because they can build the same recipe.

Understand the key used for a revision request

The examined package revision implementation requests a value using the revision-version key, package architecture and a checksum obtained from the packaging task's dependency data. It uses this result to set PRAUTO.

This is not a wall-clock timestamp counter attached to every invocation. Repeating a build request and producing a new relevant input identity are different events. Inspect the effective package version/revision fields and the service interaction when investigating an unexpected number, rather than assuming that every rebuild must increment it.

The implementation also supports recipe-specific service configuration. If one package behaves differently from others, check for that override before diagnosing the shared endpoint itself.

Treat the service's state as part of the feed's versioning history. Replacing it with a fresh empty instance is not equivalent to restarting the same service with its history intact. Before migrating or restoring it, validate the candidate packages against versions already distributed to devices.

Keep shared state and version policy consistent

The documented PR Service model does not store PR history in sstate packages. Sharing compiled cache entries alone therefore does not merge independent revision histories. The guide calls for a consistent service arrangement across builders sharing an sstate feed.

Test the intended setup with a bounded package change and both contributing workers. Inspect the resulting binary package versions and the target package manager's ordering, including a worker that restores reusable build state. Use the actual architecture and package format involved in the feed.

Build history can expose a package version moving backwards, but it is an observation aid rather than the shared numbering authority. Investigate such a report before publishing the candidate feed.

Finally, keep source selection separate: a PR Service does not pin a Git revision or choose a preferred recipe. Its job in this workflow is to make the package revision history coherent so devices can distinguish the intended newer package from the software they already have.