Choosing Between Source Compilation and Binary Hosting on Gentoo Production Servers

Decision: When to use Gentoo binhost versus source emerge

In production environments where many identical servers must be provisioned quickly, the choice between compiling every package from source and using a binary host (binhost) influences both deployment speed and system flexibility. The following guide outlines the decision, constraints, available options, trade‑offs, and a concrete validation method.

Constraints

• All binary packages must be built for the same CHOST and CFLAGS as the target systems; otherwise ABI mismatches cause runtime failures.
• The binhost must be trusted and kept in sync with the official Gentoo Portage tree to avoid propagating stale or vulnerable packages.
• PORTAGE_BINHOST must point to a reachable HTTP/HTTPS or rsync location that contains the binary packages and their Manifest files.

Supported options

Option	Description	When to use
A – Pure source emerge	Every package is built locally with emerge.	Maximum flexibility, custom USE flags, kernel patches, or when no trusted binhost exists.
B – Mixed binhost + source	Portage first attempts to fetch a binary; if unavailable it falls back to source compilation.	Mostly identical servers with occasional package‑specific customizations.
C – Full binhost (binary‑only)	Portage is instructed to use only binaries (--getbinpkg-only) and will fail if a binary is missing.	Environments where absolute consistency and minimal build time are required and all needed packages are pre‑built.

Trade‑offs

• Source: Full control over optimizations (-march,-O2,-pipe) and USE flags; longer build times, higher CPU usage on each node.
• Binhost: Dramatically reduced deployment time and uniform binary set; requires trust in the binary host and limits customization to what was built into the binaries.
• Mixed: Gives the speed benefit for the majority of packages while still allowing source builds for exceptions; adds slight complexity in tracking which packages came from which source.

Implementation and validation

1. Configure the binhost – As root, edit /etc/portage/make.conf and add or adjust the line:

   PORTAGE_BINHOST='https://binhost.example.com/gentoo'

   Replace the URL with your actual host. Ensure the host provides a Manifest file for each package directory.
2. Test binary fetch – Choose a package that is known to exist on the binhost, for example app-admin/sudo. Run:

   emerge --getbinpkg-only app-admin/sudo

   If the command succeeds, Portage has downloaded and installed the binary. If it fails with a message about missing binary, proceed to the next step.
3. Allow fallback to source – When the binary is missing or you need a custom configuration, let Portage compile from source:

   emerge app-admin/sudo

   Portage will first look for a binary; if none is found it will build the package locally using the settings in make.conf.
4. Verify the installation – Confirm that the installed package matches the expected source or binary:

   # List installed version and source
   qlist -I app-admin/sudo
   # For a binary installed via binhost, you can also compare checksums
   qpkg -c app-admin/sudo   # shows the package’s checksum as recorded in the var/db/pkg manifest

   The checksum displayed by qpkg -c should match the one in the binhost’s Manifest file for the same version.
5. Post‑upgrade consistency check – After a mixed source/binhost upgrade, run:

   revdep-rebuild

   to detect any libraries that may have been linked against incompatible binaries.

Limitations and practical checks

• Binary packages must match the target’s CHOST; using a binhost built for x86_64-pc-linux-gnu on a i686-pc-linux-gnu system will lead to runtime errors.
• Stale binhosts can introduce security gaps. Synchronize the host regularly with the official Gentoo rsync tree (rsync -av rsync://rsync.gentoo.org/gentoo-portage/ /path/to/portage) and run glsa-check -f -t all to verify no outstanding GLSA advisories.
• To confirm that PORTAGE_BINHOST is active, inspect emerge --info and look for the variable; it should appear exactly as set in make.conf.
• A quick sanity check after installing a package via binhost is to compare the file size and timestamp of the installed binary with the one downloaded from the host (both are stored under /var/cache/binpkgs when using --getbinpkg-only).

By following the steps above you can decide whether a pure source approach, a mixed strategy, or a fully binary‑only workflow best fits your production Gentoo servers, and you have a repeatable method to validate that the chosen method is working as intended.