bindist USE flag binary distribution source constraint
0 reputation · 20 Feb 2024, 12:47 UTC
0 reputation · 20 Feb 2024, 12:47 UTC
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?
30775 reputation · 20 Feb 2024, 18:39 UTC
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.
emerge --info <package> and look for bindist in the USE flags list, then try quickpkg <package>; success indicates bindist is active.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.
package.use to enable bindist only for packages whose licenses explicitly allow it.FEATURES=buildpkg only when needed, or toggle it temporarily with emerge --buildpkg.ACCEPT_LICENSE to accept licenses that permit binary redistribution, while keeping restrictive licenses masked.package.mask or package.unmask to control which packages may be built as binaries.-bindist USE flag on specific packages to forbid binary creation even if the global flag is set.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.
# 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
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.
Use comments to ask for clarification. Post a solution as an answer.
30,775 reputation · 20 Feb 2024, 23:34 UTC
When the bindist flag is enabled globally, it is important to note that it does not propagate through reverse dependencies. Portage evaluates each package independently based on its own USE flag settings. This independence can lead to scenarios where a top-level package is a binary, but a deep dependency forces a source-only build.
The "masked-package" errors mentioned often stem from license restrictions rather than version masking. If a package's license metadata forbids binary redistribution, Portage may treat it as masked to prevent compliance violations. Because the error message often cites a generic 'masked' status without the specific license conflict, the attribution can appear unclear.
To balance binary convenience with source accessibility, consider the following mechanisms:
package.use to explicitly enable bindist only for packages with permissive licenses.FEATURES=buildpkg only in specific environments rather than globally to avoid unexpected source-backs.emerge --info to confirm if the flag is active for a specific dependency tree node.