bindist USE flag binary distribution source constraint

Question

The bindist USE flag controls whether Gentoo retrieves prebuilt binaries for a package instead of compiling from source. Enabling this flag system-wide can reduce compilation time and bandwidth but may limit access to source code, affecting compliance, debugging, or future modifications. The precise goal is to establish a consistent policy for when bindist takes precedence over source availability across the package dependency graph. Are there scenarios where enabling bindist triggers masked-package errors without clear attribution? What policy mechanisms can balance binary convenience with source accessibility? Does the bindist flag propagate uniformly through reverse dependencies?

Tasadduq Burney · Answer

Answer

Enabling the bindist USE flag allows Portage to create and share binary packages only when the package’s license permits redistribution. If a dependency’s license forbids binary redistribution, enabling bindist system‑wide can cause that dependency to be masked, producing a masked‑package error that may not clearly point to the license conflict.

Confirmed facts

The bindist flag is consulted by Portage when FEATURES=buildpkg or when using quickpkg/pkgcore to generate binary packages.
It does not automatically propagate to reverse dependencies; each package is evaluated independently for its own bindist setting.
To verify, run emerge --info <package> and look for bindist in the USE flags list, then try quickpkg <package>; success indicates bindist is active.

Likely explanation for masked‑package errors

When bindist is enabled globally, Portage attempts to create binary packages for all build steps. If a package’s LICENSE metadata does not allow binary redistribution, Portage treats the package as masked (via package.mask generated from license restrictions). The error message usually shows the package name and a generic “masked” reason, without explicitly mentioning the license, which can make the attribution unclear.

Policy mechanisms to balance convenience and source access

Use per‑package package.use to enable bindist only for packages whose licenses explicitly allow it.
Keep the global USE flag disabled and rely on FEATURES=buildpkg only when needed, or toggle it temporarily with emerge --buildpkg.
Leverage ACCEPT_LICENSE to accept licenses that permit binary redistribution, while keeping restrictive licenses masked.
Apply package.mask or package.unmask to control which packages may be built as binaries.
Consider using the -bindist USE flag on specific packages to forbid binary creation even if the global flag is set.

Propagation through reverse dependencies

The bindist USE flag is not a dependency flag; it does not flow automatically to reverse dependencies. A dependent package will only inherit bindist if its own USE flags (from profile, package.use, or make.conf) contain bindist. Therefore, enabling bindist system‑wide does not guarantee that all reverse dependencies will be built as binaries; each is evaluated separately.

Verification steps

# Check license and bindist status for a package
eix -I 
equery uses 
emerge --info  | grep "USE"
# Try to create a binary package
quickpkg 
# If successful, a .tbz2 appears in $PKGDIR
ls $PKGDIR/-*.tbz2

Missing diagnostic detail

If you encounter a masked‑package error, please provide the exact package name and the output of eix -I (or equery uses ) so we can confirm whether its license allows binary redistribution.