Re: Enabling Binaries by default in Stage3s

On 8/11/26 7:08 AM, Antoine Le Gonidec wrote:

> Since any package where I set build flags distinct from the ones used for binary
> packages are automatically built from source, I am a bit suprised to see so much
> opposition for this suggestion to tweak the default setting for new install of
> Gentoo (nothing would change for a system already running right now). I guess
> there is some obvious downside that my limited experience with Gentoo is hiding
> from me.


Mixture of two factors:

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

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


...


All,

Ultimately, the user is in the best position to know whether binary
packages are something they want/need, or whether they are doing
something which depends on not downloading them. And it is impractical
for portage to just automatically know a person's use case and toggle
binaries depending.

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.

As it happens, I cared about using binaries for dependencies, enough
that I invested time and energy into reworking the test templates to
rely on --buildpkg-exclude and --usepkg-exclude. This was not free. It
is now safe to use --getbinpkg in a pkgdev tatt run, but it took work.
You cannot assume everyone using gentoo in similar conditional
automation has done so, especially if binaries were never really visible
on their radar. And portage cannot know something basically impossible
like this.

(Portage could always build from source if FEATURES=test is set, but
currently it does no such thing. You can call that a portage defect that
makes global --getbinpkg unsafe, and say we should "just fix the
defect", but the fact remains that it is unsafe *today* for this
specific automation unless you can guarantee that your tooling does a
bunch of nondefault things.)

And I definitely don't want to be the one to try to figure out how the
heck portage is supposed to decide what constitutes a "testing / ABI
transition" CFLAGS versus a "performance" one and automatically compare
binpackages to make.conf in order to dynamically enable a binhost. It
sounds incredibly fragile.

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


-- 
Eli Schwartz

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

wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCansk3wUDAAAAAAAKCRCEp9ErcA0vV5oh
AP9/OGoEqrSK0fF0N4Fbn0AI2AcGwWDB62/n9Md3b/iL+AEAohdgmlMmd+8CCbi3Fkl+LTHPgGF+
hGT3p3I7PdbW3gY=
=chwt
-----END PGP SIGNATURE-----