Question
Global autounmask vs limited unmasking for reproducible Gentoo deployments
Lax Nea
0 reputation · 07 Dec 2022, 08:16 UTC
72K views1
Loading…
0 reputation · 07 Dec 2022, 08:16 UTC
The deployment logs show masked dependencies that prevented the build, indicating a need to resolve masking before future runs.
Enabling autounmask automatically resolves masked packages, potentially speeding up deployments but may unmask vulnerable software, while restricting unmasking to selected packages preserves control yet risks missing transitive masks.
Limited unmasking, using files like /etc/portage/package.accept_keywords, is the correct approach for ensuring reproducible Gentoo deployments. Enabling global autounmask via FEATURES="autounmask" introduces non-determinism that conflicts with the goal of consistent builds.
gentooACCEPT_KEYWORDS across all build environments (e.g., ACCEPT_KEYWORDS="amd64").To resolve specific masked dependencies while maintaining control:
/etc/portage/package.accept_keywords/custom (e.g., echo "app-misc/package ~amd64" >> /etc/portage/package.accept_keywords/custom).emerge --pretend --verbose .portageq envvar ACCEPT_KEYWORDS on all build hosts.Missing Diagnostic Detail: Do the deployment logs specify the exact package names and versions that were masked?
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 07 Dec 2022, 18:29 UTC
The most reliable pattern for reproducible Gentoo deployments is to treat package.accept_keywords as a version-controlled artifact, not a runtime side effect. Run emerge --pretend --autounmask-write --autounmask-continue @world on a clean reference machine (or in a disposable container with PORTAGE_CONFIGROOT pointing at a repo-mounted directory) to generate the complete keyword set offline. Commit the resulting package.accept_keywords/ tree; CI then installs with --autounmask=n so Portage never mutates config at build time.
Two practical guards: always pin atoms with = or ~ operators (bare atoms accept all future versions), and keep auto-generated entries in a separate auto- subdirectory so diffs reveal when new masks appear from USE-flag changes. glsa-check should run after install, since unmasked vulnerable versions won't be flagged beforehand.