Which Portage settings actually prevent a locally built binpkg from being installed on a production host with mismatched USE flags?

Question

I maintain a Gentoo build host that produces binary packages for a small fleet of production servers. The goal is reproducible deployment: a package emerged locally should either install cleanly in production or be rejected with a clear mismatch, never silently installed with different dependency assumptions.

The uncertainty is around how much Portage actually enforces at binpkg install time. My understanding is that a binpkg embeds the USE flags, CFLAGS, and CPU_FLAGS_X86 of the build machine, and that --binpkg-respect-use influences whether a binpkg is accepted when the local configuration disagrees — but it is unclear to me whether this check covers the full dependency graph or only the top‑level package, and whether profile differences (desktop vs. server) between build and production hosts are detected at all. The research I have suggests mismatch detection is not enforced by default, and that behavior differs between Portage 3.0 and 3.1, which I have not verified against a specific version.

Assume a recent stable Portage 3.0.x and matching glibc on both sides.

1. Does --binpkg-respect-use reject a binpkg when the production host’s profile or package.use would produce a different dependency set, or only when the package’s own USE flags differ?

2. Is there any supported mechanism to pin or validate CPU_FLAGS_X86 at binpkg install time, or must that be handled outside Portage?

3. Which files under /etc/portage must be byte‑identical between build and production hosts for emerge --usepkgonly to be deterministic?

Tasadduq Burney · Answer

Under a stable Portage 3.0.x line, --binpkg-respect-use does not validate the full dependency graph or detect profile-level differences. It compares only the USE flags embedded in the binpkg for the target package against the host's effective USE for that same package. If they differ, the binpkg is rejected; if they match, it is accepted even when the host's profile or package.use would have produced a different dependency set. 1. Scope of the USE check The check is per-package, not transitive. A binpkg records the USE flags active at build time. At install time, Portage compares that recorded set against the effective USE for the single package being installed. Changes in package.use or profile that alter a dependency's USE—but not the top-level package's USE—are invisible to this check. Dependencies may be satisfied by already-installed packages or other binpkgs with divergent USE. 2. CPU_FLAGS_X86 There is no supported Portage mechanism that validates CPU_FLAGS_X86 at binpkg install time. The flag set is recorded in the package's build environment, but emerge --usepkgonly does not compare it against the host's CPU_FLAGS_X86. Enforcement must happen outside Portage: either keep /etc/portage/make.conf identical across hosts, or use an external pre-install wrapper to compare the recorded and local flag sets. 3. Files required for deterministic emerge --usepkgonly For the same binpkg to be selected and installed deterministically, these must be byte-identical between build and production hosts: /etc/portage/make.conf (at minimum USE, CFLAGS, CXXFLAGS, CPU_FLAGS_X86) /etc/portage/package.use/ (or the package.use file) The /etc/portage/profile symlink, so both hosts resolve to the same profile Optionally package.license and package.accept_keywords when they influence dependency selection or USE Verification To confirm the behavior on your fleet, build a package with a non-default USE flag on the build host and inspect its recorded USE with qtbz2 -f .tbz2 or equery uses . On a production host, flip that flag in package.use and run emerge --binpkg-respect-use --usepkgonly --pretend ; the binpkg should be rejected. Next, alter CPU_FLAGS_X86 on the production host and repeat; Portage will proceed, confirming the lack of CPU flag validation. Version caveat Behavior around dependency-level USE verification changed between Portage 3.0.x and 3.1. The description above reflects the conservative 3.0.x behavior you specified. If you are in fact running a 3.1 series, please confirm the exact version, because the recommendation for whether additional external graph validation is required depends on it.

Which Portage settings actually prevent a locally built binpkg from being installed on a production host with mismatched USE flags?

1 answer

1. Scope of the USE check

2. CPU_FLAGS_X86

3. Files required for deterministic `emerge --usepkgonly`

Verification

Version caveat

Your perspective belongs here.

0 question comments