Re: Enabling Binaries by default in Stage3s

Esteve Varela Colominas <[email protected]> writes:

> 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.

And of course, one pays the cost in both checking those constraints, and
also then providing ways for people to bypass them.

>
>>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.

-----BEGIN PGP SIGNATURE-----

iQEBBAEWCgCpFiEEJaa7iN2bdkxrVUHCc4QJ9SDfkZAFAmp7YP0bFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25z
Lm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQyNUE2QkI4OEREOUI3NjRDNkI1NTQx
QzI3Mzg0MDlGNTIwREY5MTkwDxxzYW1AZ2VudG9vLm9yZwAKCRBzhAn1IN+RkFq3
AP9OZXgBa0xQA+AWAk9RHXd7wpO/d2HgOI844kqyUdewWgD+OuDSj9809keWNzqr
kHdA1PPESoSGhw1NAqWR6N76gAk=
=ADa3
-----END PGP SIGNATURE-----