Re: Enabling Binaries by default in Stage3s

El 11 d’agost del 2026 15:34:23 CEST, Eli Schwartz <[email protected]> ha escrit:
>As one example of automation which breaks with binpackages, automated
>stablereq testing via `pkgdev tatt` builds and installs packages with
>and without FEATURES=test. It may be desirable to install dependencies
>from binaries for speed, but it is *vital* that the package being tested
>is never installed from a binary, shortcutting FEATURES=test for
>packages with a test phase but no USE=test. Using binaries would defeat
>the entire purpose of *testing* a stablereq.

I wonder at what point enough testing and automation tools will be using binpkgs (whether official binhosts or just a local cache to aid with reinstalls and USE changes, like my setup does), where such a change won't affect much.
It really feels like a no-brainer in the majority of testing and automation efforts, where you really don't want to unnecessarily build things more than once.

That said, ideally portage would honor the exact same /etc/portage settings in both ebuilds and binpkgs (anything that can affect the installed contents), such that a user would not need to care about how a package was merged, but as it stands, a user needs to be aware of the caveats, and I'm not sure it'll ever be perfect lest portage become Nix. Perhaps at some point there will be enough heurestics to cover everything but niche cases. There's been good progress in this area lately.

>But I would be very supportive of "strongly
>recommending it in the handbook".

I echo this sentiment. I think it's important for new users to be able to get a usable system as quickly as possible, without getting hung up on customizing flags and kernel options and whatnot. Except for the profile choice, I think it's much safer and easier to customize and rebuild things after. Having a working setup to compare to makes testing individual changes a bit easier.