Re: Enabling Binaries by default in Stage3s

On 8/11/26 8:34 AM, Eli Schwartz wrote:
> 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".
>
>


Sort of picking a random reply since this is about where this idea 
occurred to me.

Gentoo is about choice, always has been.  A couple options I see. Have a 
stage3 tarball for compile from source users and another for binary 
users.  Each one comes set up to use the method of install the user 
wants.  Second possibility.  Have a tarball, just one, that once 
unpacked and chrooted into, one can type in a command and select which 
method they want to use, this should be able to automate for those using 
scripts as well.  The eselect command comes to mind but there may be 
other methods or even better ideas on that.  From there on, it uses the 
method the user wants.  There may be other ways that occur to others as 
well that may even work better than one of those.

Since Gentoo has always been about choice, this gives that.  A user 
picks the path they want and follows whatever path that gets them 
there.  Either a separate tarball or selecting a path once chrooted into 
the install.  This should make it so that everyone gets want they want, 
a choice on how to install and then the proper path to do so.

Given the history of Gentoo tho, I think the default should remain as 
compile each package from source.  Gentoo has done it that way since it 
was born.  Changing that now would likely lead to some confusion.

I might also add, it seems there is a lot of support for a binary 
version of Gentoo, especially for laptop/notebook/etc systems that don't 
handle compiles very well.  Maybe this is a good time for a minor fork 
of Gentoo into a binary install system and maybe call it Gentoo-bin or 
something.  It can still be Gentoo, use the same package manager and all 
but is a different system.  If there is enough support to do it this 
way, it should be easy to switch from one to the other as well.  In 
other words, install a binary system for a quick setup and then switch 
to compile from source for updates and tweaking the system settings.  
Switching from compile to binary should be easy as well.  This is just a 
thought and of course would require enough people to actually maintain 
it as well.  Given how many use this method, there just may be enough to 
help support this path.

I started using Gentoo in 2003.  I can't imagine using anything else.  I 
like the idea of a binary install especially for those where only that 
will work on a piece of hardware.  While I have never used binaries as a 
whole, I see the need for it.  If I bought a laptop that was 
underpowered, I'd want to install Gentoo on it and use the binary 
method.  Having that choice, in my opinion as a long time user of 
Gentoo, is a good idea.  Some systems today, must have that.

I'm going back to my hole now.  Maybe someone can take this and think on 
it, maybe even come up with a much better plan.  Maybe this will spark 
something good.

Dale

:-)  :-)