Re: Enabling Binaries by default in Stage3s

Le Tue, Aug 11, 2026 at 09:34:23AM -0400, Eli Schwartz a écrit :
> - For some people, "watching text scroll by endlessly is fun for the
>   whole family", i.e. the act of performing the compiles yourself is a
>   religious experience. Religion doesn't have to make sense -- people
>   want to do it themselves, goshdarnit.

Watching disk defragmentation on Windows 98 played an actual part in what
was going to turn into a growing fascination, leading me to become a Debian
Developer many years later. And I still tend to spend too much time watching
stuff I automated print lines on the screen, despite that act of staying
here to watch kind of defeating the purpose of automation.

So I very much support this argument, because I recognise myself easily in it ;)


> - Build flags means USE flags to you, and you are correct that those
>   will be built from source automatically. It does not mean CFLAGS.
>   If one has set CFLAGS which differ from what the binhost builds with,
>   those explicitly do not apply and your prebuilt binaries will not use
>   them. This may be okay if the CFLAGS which aren't respected, are
>   -march=native, since you're just trading off dubious speed benefits
>   for much faster installation time (the binhost provides -march=x86-64
>   as well as -march=x86-64-v3, although it defaults to the former, and
>   the latter generally provides most of the advantages of -march=native)
>   and thus binaries would not be a breaking change.
> 
>   But Sam's statement about it being a breaking change for automation
>   has some important wording about CFLAGS: "which is relevant for
>   reasons other than performance, like testing, or transitioning ABIs".
>   So, yes. Ignoring CFLAGS can be a breaking change, depending on what
>   CFLAGS one actually uses.

Thanks, this is indeed the part I was missing. It’s actually a problem
I had to think about because of my 3 computers, 2 are of a similar era
but 1 is much older, and still I would like to provide my own binpkgs
host for all 3.

Yet, I did not think about it in this context, and missed the wider use
of CFLAGS and the broader impact using binpkgs by default could have.


> (…)
> So: despite being in the camp that thinks refusing to use a binhost
> because "the purpose of gentoo is to compile it yourself, with blackjack
> and optimizations", is silly? I still don't think I can condone enabling
> --getbinpkg by default. But I would be very supportive of "strongly
> recommending it in the handbook".

This recommendation would fully fit my use case, of a new user installing
Gentoo for the first time who would most probably benefit from these binary
packages.

And to be fair, the documentation is already at least in part there. Because
I ended up enabling --getbinpkg by default despite none of my Gentoo mentors
suggesting it (or doing it themselves), so I must have picked it from the
documentation at some point.

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

iHUEABYIAB0WIQSUsdxM90hewW6X7Jhja3j5HOuA2AUCanu8wQAKCRBja3j5HOuA
2EGKAP9meirZGgDH2g3jEIdWK6MZ0d5qCbf7AQ00nsjhWjfRnwD+PHSCvfFgf1wu
BIj0jvKMHIRfuf62SSJP2lFuxVgzSAY=
=ojLH
-----END PGP SIGNATURE-----