Gentoo on a low-RAM build host: prebuilt binary packages or --buildpkg with local source builds?

Short version: on a single machine, --buildpkg alone does nothing for your OOM problem — the first compile is identical to a plain source merge. The practical fix for webkit-gtk and libreoffice is selective use of the official binhost for exactly those packages, keeping everything else source-built with your USE flags. Below is the reasoning and the verification workflow, assuming a current Portage on a stable amd64 profile.

1. Does --buildpkg help a single low-resource host?

Not for the build that hurts. --buildpkg (or FEATURES="buildpkg") runs the exact same compile and link steps as a normal merge; it just additionally writes a .gpkg.tar into $PKGDIR. Peak memory during the link of webkit-gtk is unchanged, so the OOM risk on the first build is unchanged.

Where it does pay off on one machine:

• Rebuilds and downgrades. If an update breaks something, you can roll back to the archived binary in seconds instead of recompiling.
• Repeated merges. emerge --usepkg can reuse your own binaries for reinstalls, binpkg-triggered rebuilds, or after a failed experiment with USE flags — as long as USE and -march still match.
• Disaster recovery. A binpkg of your toolchain and @system set is a fast path back from a broken chroot or rescue boot.

So: enable buildpkg as cheap insurance, but don't expect it to solve the large-package problem. That requires either not building them locally at all (binhost) or reducing peak memory (fewer parallel jobs, more swap/zram, possibly a tmpfs size cap on PORTAGE_TMPDIR).

2. Selective per-package binhost use

Yes. Enable binary fetching globally, then restrict which packages are allowed to resolve as binaries:

# /etc/portage/make.conf
FEATURES="getbinpkg"
PORTAGE_BINHOST="https://distfiles.gentoo.org/releases/amd64/binpackages/23.0/x86-64/"

Then use /etc/portage/package.use-style confining via /etc/portage/binrepos.conf plus per-package control. The cleanest mechanism on current Portage is to allow binaries only where you want them:

# /etc/portage/package.binhost (conceptually: restrict binary use)
# Use emerge option scoping instead — see below

In practice the most reliable selective approach is to keep getbinpkg enabled and add --usepkg to your default opts, while pinning the big packages' USE flags to match the binhost build (check the binhost's USE settings; for the standard amd64 binhost these are the profile defaults). Portage only uses a binary when the USE set matches exactly, so for the two giant packages you accept the stock USE flags; everything else keeps your custom flags and simply never matches a binary, so it builds from source. If you want to be explicit, you can also run the big merges separately:

emerge --ask --usepkgonly --oneshot www-client/webkit-gtk app-office/libreoffice

--usepkgonly fails rather than falling back to source if no matching binary exists — useful so you never accidentally kick off an 8-hour link job.

3. Verifying binary vs. source resolution before a world update

Dry-run with binary resolution enabled and read the merge list:

emerge --pretend --verbose --getbinpkg --update --deep --newuse @world

In the output, each line is annotated: [binary R ] means a matching binpkg will be fetched; [ebuild R ] means a source compile. Any large package showing ebuild is a mismatch — usually a USE flag difference. To see why, compare:

emerge --pretend --verbose --usepkgonly app-office/libreoffice

which reports the binary's USE set, against your configured flags in package.use. Aligning the flags (or dropping your override for that package) flips it to binary. After a real merge, /var/log/emerge.log and qlop -v confirm what actually happened.

Assumptions and caveats

This assumes a current Portage (gpkg binpkg format, 23.0 profiles) and the official Gentoo amd64 binhost; exact binhost URIs and the precise per-package confining syntax have changed across releases, so verify against man make.conf and the wiki's binary package guide on your system before committing. One open detail that would sharpen the recommendation: how much RAM and swap you actually have — with 8 GB plus generous zram, even webkit-gtk can be built locally with MAKEOPTS="-j2" and a capped number of link jobs, which may beat maintaining USE-flag alignment with the binhost.