Binary and source distributions¶

Every program on a Linux system was compiled from source code at some point. The question that separates distributions is where and when that happens.

Debian, Ubuntu, the RHEL family and Arch compile each package once, on the distribution's build servers, and ship the result. Every machine that installs a given version of a package gets the same binary, built with the same compiler, the same options and the same optional features. Gentoo ships recipes instead. Portage downloads the upstream source code and compiles it on your machine, with options you choose.

Both approaches produce a working system from the same upstream code. They differ in who makes decisions about features, how long an installation or upgrade takes, how predictable the result is, and how much responsibility falls on the administrator.

Binary distributions: decisions made once, for everyone¶

A binary package is a snapshot of one build. When a Debian maintainer packages a program, they decide which optional features to enable at compile time: whether a web server links against a particular TLS library, whether a mail client is built with LDAP support, whether a tool gets its graphical front end. Usually the answer is "enable everything most users might want", because the same binary has to serve a laptop, a container and a mail server. Where features pull in large dependency trees, distributions split one source package into several binary packages (a library, its development headers, a command-line tool, a GUI) so that users install only what they need.

This model has strong advantages:

Speed. Installing or upgrading means downloading and unpacking. A full system upgrade takes minutes.
Uniformity. Every installation runs the same bytes. A bug report, a security advisory or a vendor certification applies to every machine with that package version.
Verifiable provenance. The distribution signs what it built (see How package management works), and reproducible-builds projects check that anyone can rebuild the same bytes from the published source.
No build toolchain needed. Production servers don't need compilers, which some security policies forbid.

The cost is flexibility. You get the features and the build options the distribution chose. If you need a compile-time option they didn't enable, you rebuild the package yourself, and then you own that rebuild for every future security update. Each binary family has tooling for it (Debian source packages, RPM .src.rpm files and spec files, Arch's PKGBUILDs and makepkg), but it sits outside the normal update path.

Binary distributions also have to choose a baseline CPU. A package built for every x86-64 processor can't assume newer instruction set extensions; RHEL 10 raised its baseline to the x86-64-v3 level, which drops support for older processors in exchange for faster code on current ones. AlmaLinux 10 also publishes a separate x86-64-v2 build for those older processors.

Gentoo: decisions made on each machine¶

Gentoo's ebuild repository contains, for each package version, an ebuild: a Bash script that says where to download the source, how to configure, compile and install it, and which dependencies and optional features it has. Portage runs the ebuild on your machine and records the result in its database exactly as a binary distribution records an installed package.

What makes this more than "compile everything yourself" is the set of mechanisms that decide how each package is built.

USE flags¶

A USE flag is a named, optional feature, such as ssl, ldap, X or systemd. An ebuild declares which flags it understands and what each one changes: a configure option, an extra dependency, an installed file. You set flags globally in /etc/portage/make.conf and per package in /etc/portage/package.use, and Portage computes the dependency graph from the result. Turning ldap off on a mail server means the LDAP client libraries are never built or installed, and never need security updates there.

USE flags are why Gentoo's dependency resolution is more involved than other families': the dependencies of a package depend on its flags, and changing one flag can require rebuilding every package that uses it, which emerge --newuse (-N) takes care of.

Profiles¶

Nobody sets hundreds of flags from scratch. A profile, selected by the /etc/portage/make.profile symbolic link (eselect profile manages it), supplies the defaults: the default USE flags, the packages in the base system, flags that are forced or masked on that architecture, and settings such as the init system. default/linux/amd64/23.0/no-multilib is an OpenRC profile without 32-bit libraries; profiles ending in /systemd select systemd instead, and desktop profiles enable the flags a graphical system needs. Profiles are layered, so your make.conf and package.use only record where you differ from the profile.

Keywords: stable and testing¶

Every ebuild carries keywords per architecture: amd64 means the version is considered stable on that architecture, ~amd64 that it's in testing there. ACCEPT_KEYWORDS in make.conf decides which a system accepts (a stable system accepts only amd64), and /etc/portage/package.accept_keywords makes exceptions for individual packages. This is how Gentoo lets one installation run mostly stable software with a few packages from testing, something binary distributions offer only by adding whole extra repositories.

Binary packages on Gentoo¶

Building everything locally is slow: a large desktop or a toolchain update can take hours. Portage has always been able to save what it built as a binary package (the buildpkg feature, or quickpkg afterwards) and install from binary packages instead of compiling (--usepkg, -k). Administrators of several similar machines build once on one host and serve the packages to the others.

Since the end of 2023, Gentoo also runs an official binary package host for amd64 and arm64, built with the default flags of the main profiles and signed with a Gentoo key. A system configured for it in /etc/portage/binrepos.conf and run with --getbinpkg (-g) installs pre-built packages whenever one matches its USE flags and profile, and compiles from source only where it differs. This makes Gentoo a hybrid: binary speed for the common case, source builds where you made a different choice.

Trade-offs¶

	Binary distributions	Gentoo
Who chooses build features	The distribution, once	The administrator, per machine (USE flags)
Install and upgrade time	Download and unpack	Compile, unless a matching binary package exists
What runs on each machine	Identical across installations	Can differ between machines with the same package version
Toolchain on production hosts	Not needed	Needed, unless everything comes from a binary host
Attack surface	Optional features usually compiled in	Unused features can be left out entirely
Effort to deviate from defaults	Rebuild and maintain your own package	Change a flag; Portage rebuilds
Support and certification	Vendors certify against known binaries	Uncommon

Neither model is better in general. Binary distributions suit fleets where uniformity, support contracts and short maintenance windows matter. Gentoo suits systems where control over each feature matters more than build time, and administrators who want the package manager to be a build system. Gentoo's binary host and the rebuild tooling of binary distributions have narrowed the gap from both sides.

Rolling and point releases¶

A second, independent axis is how a distribution changes over time.

A point-release (or fixed-release) distribution publishes numbered releases. Within a release, package versions are frozen and only receive fixes: security patches and important bug fixes are backported to the version the release shipped with, rather than replacing it with a newer upstream version. Debian publishes a new stable release about every two years; Ubuntu publishes a long-term support release every two years; RHEL publishes a major release roughly every three years with minor releases in between, and AlmaLinux and Rocky Linux follow it. Moving to the next release is a deliberate, planned upgrade.

A rolling distribution has no releases. Packages move to new upstream versions continuously, and an installation stays current by upgrading regularly. Arch and Gentoo both work this way. There's no big upgrade every few years, but there's a steady stream of smaller changes, some of which need attention: a configuration format changes, a service is renamed, a news item asks for a manual step.

	Point release	Rolling release
Package versions	Frozen per release; fixes backported	Follow upstream continuously
Behaviour changes	Concentrated in release upgrades	Spread across regular updates
Old versions of a package	Usually still in the release's repositories	Usually gone from the repository once replaced
Suits	Long-lived servers, certified workloads	Systems that need current software and get regular care

The release model shapes the day-to-day tasks in this section. On a point release, holding a package or rolling back an update is usually safe and the older version is easy to find; on a rolling release, a held package drifts further from the rest of the system with every update, and Arch explicitly doesn't support partial upgrades. Arch keeps a dated archive of every package, and Gentoo keeps older ebuilds in the repository for a while; both make rollback possible, but neither is designed around it. See How to hold a package at its current version and How to roll back a package update for the details per family.