Gentoo ships 89 GB of binaries now

On 5 January 2026 the Gentoo project counted 89 GB of amd64 binary packages sitting on its own mirrors. Sabayon spent eleven years arguing that a source distribution needed exactly that, was told for most of them that it had missed the point, and stopped shipping in March 2019. This is what got absorbed, what did not, and why the idea won is not the same sentence as the project was right.

The objection to a binary Gentoo is not stupid

State it at full strength, because the weak version — compiling is character-building — is a straw man that nobody serious ever argued.

A source distribution is not a slow binary distribution. It is a distribution where the build is the configuration. USE flags decide which optional dependencies exist at all, so ffmpeg on one machine and ffmpeg on another are different binaries with different link maps and different attack surfaces. The profile decides the libc, the init system and the hardening. CFLAGS decide the instruction set. Take a prebuilt package from a stranger’s build farm and every one of those decisions was made by the stranger. The four serious objections follow from that, and they are worth naming separately:

1. Configurability. One binary is one point in a combinatorial space. Ship binaries and either the space collapses to whatever the farm built, or the binaries are ignored so often that they are decoration.
2. Trust. An ebuild is a few hundred readable lines and a checksummed upstream tarball. A binary is a build you did not witness on a machine you do not administer.
3. Responsibility. A binary distribution owes its users a support matrix and a security response. A source distribution can legitimately answer “here is the ebuild, here is the bug”. Different promises, and the second is much cheaper to keep.
4. The social argument. The build was a toll. It selected for users who could read a compiler error, which made the bug reports usable — a real engineering asset that no CI system replaces.

Gentoo itself has never conceded the frame. Its December 2023 announcement of the binary host says in its own words that Gentoo “still remains a source-based distribution”, and the mechanism it shipped is built around that sentence rather than around abandoning it. Hold on to that, because it turns out to be the whole answer.

The numbers, from the project’s own count and from mine

2026·01·05Gentoo’s annual retrospective for 2025 put hard figures on a project that is usually described in adjectives: 31,663 ebuilds covering 19,174 distinct packages; 112,927 commits to the ::gentoo repository during 2025, down from 123,942 in 2024; 9,396 of those commits from 377 external contributors; 154 installation stages rebuilt every week; EAPI 9 finalised; and 89 GB of binary packages for amd64 on the mirrors. The same document reports the Gentoo Foundation’s income for the fiscal year ending 30 June 2025 as $12,066.

Those are the project’s numbers. Here are mine, because a figure you cannot re-derive is a figure you should not repeat. The binary host publishes a plain-text Packages index per configuration, and it is a file anyone can fetch and count. Downloaded and parsed on 4 August 2026:

That is one of eight amd64 configurations published side by side under binpackages/23.0/ — x86-64, x86-64-v3, x86-64_hardened, x86-64_llvm, x86-64_musl, x86-64_musl_hardened, x86-64_musl_llvm and x32 — and 23.0 is the only profile directory left on the host. Two of the eight carry nearly all of the weight. Counted the same way on the same day, x86-64-v3, which is the same package set rebuilt for the x86-64-v3 microarchitecture level, held 19,555 instances and 77.4 GB: within a few per cent of the generic index rather than a fraction of it. Gentoo’s own test for whether a machine can use it is ld.so --help, which prints the glibc-hwcaps levels the loader will search. The remaining six are small beside those two — hardened 1,064 instances and 3.0 GB, LLVM 926 and 3.9 GB, musl 702 and 2.2 GB, musl-hardened 711 and 2.2 GB, musl-LLVM 760 and 2.3 GB, x32 825 and 1.6 GB — and the wiki says why rather than leaving it to be inferred: for those configurations only the packages that appear in a stage3 are built, and they are rebuilt weekly rather than daily. The two big indexes are the product; the six small ones are the toolchain.

Which forces a caveat on the headline number rather than a flourish. Add the SIZE fields of all eight indexes and the total is 172.7 GB, not 89 GB. The retrospective does not say what its figure counted — one index, all of them, or what the mirrors actually occupy on disk after identical files are shared — and it was published seven months before these indexes were fetched, over which time the archive grew. So: 89 GB is the project’s own count, correctly dated to 5 January 2026, and it is the number in this piece’s title because it is the number Gentoo published. What a reader can verify today is the per-index figure, and the generic amd64 index alone is 80.1 GB of it.

What Entropy actually was

Sabayon Linux · Ended · verified 2026-08-04

2007·12·24Entropy shipped as a beta in Sabayon 3.5 Loop 1, and as a supported component in 3.5 on 1 July 2008. It was not a package manager in the sense that Portage is one. It was a binary infrastructure: a server side that built packages, a repository format, a client library, equo on the command line and, later, Rigo as the graphical front end — Rigo itself a replacement for an earlier GUI called Sulfur. There was grant money behind it, which is unusual enough in distribution tooling to be worth recording: NLnet’s project register still lists Sabayon, filed under 2009, for “creating a fast binary package manager using relational databases”. That page also carries the clearest statement of the design goal anywhere on the public record — a SQLite-backed binary manager smart enough that two or three developers could maintain about 12,000 packages.

The property that mattered is the one most retellings drop. Sabayon’s binaries were built from the Gentoo tree — the testing branch of it — so a Sabayon system remained binary-compatible with a Gentoo system configured the same way. Sabayon was not a fork with a package manager bolted on. It was Gentoo with a build farm in front of it, and Portage stayed installed and usable underneath.

Which produced the defect that dogged it for a decade: two package managers with two databases describing one filesystem. Entropy learned about Portage’s work only when told to, so the documented workflow was a synchronisation command after every source-side install, plus a client option to stop Entropy replacing locally compiled packages with generic ones.

“Mixing Entropy and Portage is for advanced users” is the standing warning in Sabayon’s own documentation, and it is the honest summary. The dual model bought convenience at the cost of a coherence problem that no amount of tooling fully closed.

How much of the 2008 objection was technical, and how much was cultural

Separating the two is the useful exercise, because they have had opposite fates.

The configurability objection was technical and it was correct. Entropy’s repositories carried one build per package. If your USE flags differed from the farm’s, you took the farm’s build or you compiled — and the client had no way to express “this binary matches me closely enough”. The trust objection was technical too, and here the received story is wrong in Entropy’s favour. Entropy shipped public-key verification: a repository security layer built on GPG with its keyring at /etc/entropy/gpg-keys, per-repository public keys fetched and installed on demand, and a gpg signature stored alongside the SHA-1, SHA-256 and SHA-512 digests of every package. When a signature failed to match, the client aborted the merge.

What it did when it could not check is the part that aged badly. If GnuPG was unavailable, or the repository’s public key was missing or expired, Entropy printed a warning and carried on installing.

The first string is a soft failure; the second is a hard one. Eighteen years of supply-chain incidents later, the interesting question about a binary host is not whether it can verify, but what it does when verification is merely absent. Sabayon answered “continue”. In 2026, Portage answers “stop”, and it changed that answer very recently.

The responsibility objection was also technical, and it is the one Sabayon never solved: one person and a small team cannot promise a security response across a full desktop archive. The dates say so plainly. The last Sabayon release was 19.03: built on 22 March 2019 and on the mirrors five days later, per the release files themselves rather than the 31 March announcement date the reference pages carry. The final commit to the Entropy repository landed on 7 September 2020. The full shutdown sequence is its own piece — What happened to Sabayon Linux.

The social objection was cultural, and cultural objections do not get solved. They get outvoted or they persist. This one persisted, and it is still the substance of most dismissals of a binary Gentoo — which is worth saying plainly, because an argument about who belongs is not improved by being restated as an argument about correctness.

What Gentoo does natively in 2026

Gentoo Linux · Shipping · verified 2026-08-04

2023·12·29Gentoo announced an official binary package host with more than 20 GB of packages for amd64 and arm64, and shipped the configuration for it inside the stage tarballs, at /etc/portage/binrepos.conf/gentoobinhost.conf. On 4 February 2024 a second amd64 archive appeared, built for the x86-64-v3 instruction set. By January 2026 the amd64 total had reached 89 GB.

On a current system the whole feature is four decisions. A binary repository is declared in /etc/portage/binrepos.conf:

[gentoobinhost]
sync-uri = https://distfiles.gentoo.org/releases/amd64/binpackages/23.0/x86-64
priority = 10

Fetching is a flag, --getbinpkg or -g, made permanent either through FEATURES="getbinpkg" or through EMERGE_DEFAULT_OPTS in make.conf. The world upgrade in Gentoo’s own announcement reads:

emerge -uDNavg @world

The letters are worth unpacking rather than pasting: update, deep, new-use, ask, verbose, get-binary-packages. Their uppercase relatives -K and -G are the strict ones, failing rather than falling back to a build — the flags to reach for when the point is that nothing should compile.

Then the part that answers the 2008 trust objection directly, and it deserves credit in the middle of an argument that is not going Gentoo’s way elsewhere:

2026·05·03Portage 3.0.78 enabled OpenPGP signature verification by default for every binary repository (bugs #945384 and #969086), and the project published a news item saying so. Verification requires the newer gpkg container format; the older xpak format cannot be verified and is skipped or ignored accordingly. The change had been staged: 3.0.74 on 1 January 2026 added the per-repository verify-signature option, and 3.0.77 on 23 January 2026 moved fetched remote packages to /var/cache/binhost/${NAME} so that packages you built are no longer mixed with packages you downloaded.

What changed in May 2026 is narrower than “Gentoo added signatures”, and the narrowness is the point. Signed packages were verified from the day the host opened: the 2023 announcement states that GPKG packages have their signature checked and installation is refused if the check fails. The gap was the other case. The older xpak format carries no signature at all, and until 3.0.78 a repository serving unsigned packages was installed from anyway unless the user opted in with FEATURES="binpkg-request-signature". Which is Entropy’s warn-and-continue reached from the opposite direction, and it stood from the host’s launch until May 2026. What 3.0.78 changed is the default, not the capability.

Now Portage does not warn and continue. On a bad or untrusted signature it raises InvalidSignature("GnuPG verification failed"); on a missing one, MissingSignature. Users running their own binhost have to sign their packages — FEATURES="binpkg-signing", with gpkg-sign for packages already built — or opt out explicitly:

[DEFAULT]
verify-signature = false

Or system-wide, in make.conf:

FEATURES="binpkg-ignore-signature"

The trust helper getuto is what keeps that from being a support disaster: Portage calls it automatically with --getbinpkg or --getbinpkgonly, and it installs the Gentoo release engineering keys into the verification keyring. Users of the official host had nothing to do on upgrade day, and the news item’s own explanation is blunter than any praise for the helper — the documented setup had asked for signature verification all along, and a system that had not been configured for it would already have been failing early. The signing keyring lives at /root/.gnupg, the verification keyring at /etc/portage/gnupg, and the wiki is explicit about the trap in between: “trusting the key marginally or less will not work”.

That is a stricter default than any binary Gentoo derivative has shipped, including the one that invented the category.

Every equo command, and what to type instead

If a script or a muscle memory still says equo, this is the section you came for. The left column is every top-level command in the client/solo/commands/ directory of the Entropy source that ever did package management — the real set, not a remembered one — and the three the client hides from its own equo help are dealt with in the note under the table. The right column is what a current Gentoo system does instead. Where there is no equivalent, the row says so rather than inventing one.

Three commands are missing from that table because they were never package management. equo moo, equo yell and equo lxnay are marked HIDDEN in the source, so equo help never listed them. The third prints an ASCII cow saying “Hail to the king, baby!”, and the one-line description registered with it is bow to lxnay — lxnay being Fabio Erculiani, whose design shop this domain was before any of the rest of it existed. An Easter egg that doubles as provenance.

Why you still get a build sometimes, and how to read the decision

The single most common complaint about the binary host is that a system with --getbinpkg set starts compiling anyway. That behaviour is --binpkg-respect-use, it is on by default unless --usepkgonly or --getbinpkgonly is in play, and the manual page is blunt about what it does: emerge ignores binary packages whose USE flags do not match the current configuration. It is the configurability objection of 2008, answered by refusing to install a package that would quietly not be the package you configured.

The other half of the answer is a format decision, and it is the part that never gets mentioned. Portage’s binpkg-multi-instance feature lets one version exist as several builds, and the official host uses it heavily. In the index fetched for this piece, 3,178 of 8,827 package-version atoms had more than one build — and that number has to be split before it can be used for anything. In 1,514 of those atoms the builds carry genuinely different USE flags. In the other 1,664 the USE strings are identical and the builds differ some other way, typically a rebuild against a dependency that changed underneath them. Counting builds and counting choices are not the same operation, and most write-ups do the first while claiming the second. LibreOffice 25.2.7.2-r1 was present twelve times in six distinct USE configurations, differing on bluetooth, eds, gstreamer, kde and the Python implementation they were built against. Firefox 140.13.0 was present four times in four, differing on pgo, pulseaudio and gnome-shell. Blender 4.4.3 was present forty-one times — in five configurations.

So the modern answer to “one binary cannot fit every USE combination” is not that the space collapsed. The host ships the popular slice of it, Portage matches against that slice, and declines rather than approximating. To see which way a package went, read the first field of the emerge output: [binary means it will be installed as built, [ebuild means it will be compiled. Since 3.0.78 the flags column also carries a g, documented as “remote binary (automatically download from binhost)”.

emerge -pv --getbinpkg @world

If a package you expected to arrive prebuilt shows [ebuild, the useful next step is to compare its USE line against the host’s, rather than to add -K and hope.

What Gentoo still does not do, and the shape of the gap

Every part of Sabayon that was infrastructure now exists upstream. Nothing that was curation does, and the difference is visible in a single line of the index header.

The binary host builds under ACCEPT_LICENSE: @FREE @FREE @BINARY-REDISTRIBUTABLE vim.org as-is. A host that redistributes to the public cannot ship what it is not licensed to redistribute, and the consequences are checkable. On 4 August 2026, the x86-64 index contained no x11-drivers/nvidia-drivers, no sys-kernel/linux-firmware, no app-arch/unrar, no media-fonts/corefonts and no www-client/chromium — a 20 KB www-client/chromium-common is there, and it blocks the browser rather than providing it, which is worth knowing before a grep convinces anyone otherwise. It did contain Firefox 140.13.0, LibreOffice 25.2.7.2, Plasma 6.6.6, GNOME Shell 49.7, Mesa 26.0.8, GCC 17.0.0_p20260802, Clang 22.1.8 and Rust 1.95.0 — which is to say, all of the packages whose absence from a binary host would make the host pointless, and none of the packages a laptop needs before its wireless card works.

Add the other two absences. Gentoo ships no graphical installer; the Handbook is the installer. Gentoo ships no curated desktop; profiles and package sets are ingredients, not a product. What Sabayon sold was a DVD you booted and clicked through, finishing with a working KDE desktop, a proprietary graphics driver already loaded and the codecs already selected. Each of those four things is what an upstream binary host is structurally unable to provide — either because of licensing, or because it is an editorial act rather than a build.

That gap is the whole reason a Gentoo-derived desktop distribution still has a reason to exist in 2026, and it is what the projects in the appendix — and the five compared in the alternatives piece — are competing over.

An idea can win and its champion still lose

This section is opinion, argued from the record above rather than asserted.

Sabayon’s technical thesis — a source distribution can host binaries without ceasing to be a source distribution — is now Gentoo’s shipping position, at a scale Sabayon never reached, with a verification default Sabayon never adopted. On the merits, the argument is over and Sabayon won it.

It won it in the way that is worth nothing to the winner. Being early is indistinguishable from being wrong right up until the moment it isn’t, and the interval is where projects die. Sabayon carried the cost of the idea for eleven years: the build farm, the ISO pipeline, the repository format, the client, the GUI, the support load of two package managers on one filesystem, and the reputational drag of being called the distribution for people who did not really want Gentoo. Gentoo picked the idea up in 2023 with a release engineering team, mirror capacity and a signing key, and made it work in two years. That is a story about what infrastructure costs and who can afford it — though the same retrospective is a reminder that the winner is not rich either: $12,066 of income to the Gentoo Foundation in the year to 30 June 2025, another $8,471 through Software in the Public Interest, $104,831 in the bank. The distinction is not money. It is a release engineering team, mirrors that already existed, and a signing key people already trusted.

There is a narrower claim that I think is also true and is easier to defend: the specific engineering decision that made Entropy interesting — building the binaries from the real Gentoo tree so that the system stayed compatible with plain Gentoo — is exactly the decision Gentoo’s own binhost makes. The derivative distributions that instead built a parallel tree are the ones whose users are stuck when they leave. The idea that survived is not “Gentoo should have binaries”. It is “binaries should be a cache of the source tree, never a substitute for it”. That sentence describes --binpkg-respect-use as accurately as it describes Entropy in 2008.

Appendix: three other answers to the same problem

Luet, and MocaccinoOS. MocaccinoOS · Shipping · verified 2026-08-04 The project that inherited Sabayon’s people replaced Entropy with Luet, a package manager written in Go that treats container images as the distribution channel. It is a different bet: not “binaries built from the source tree”, but “the source tree is one input to an OCI build”. It gives up the property this piece keeps returning to. Entropy shipped the Gentoo tree, compiled; a Luet layer is an image assembled from a pinned snapshot of that tree, and the repository offers layers and applications in the hundreds where Entropy offered packages in the thousands. This site examined that succession at length in MocaccinoOS: the successor, or the estate?, including the Sabayon-to-Mocaccino migration path that still exists and what it does not carry across.

Sisyphus, and Redcore. Redcore Linux Hardened · Shipping · verified 2026-08-04 Redcore took the most conservative route of the three: Sisyphus wraps Portage, gentoolkit and portage-utils in an apt-shaped interface — its own command-line client says exactly that, in one line, at the top of its help — and the binary packages it installs are built with Portage on Redcore’s servers and installed by Portage itself, through the same --getbinpkg machinery described above. Nothing is replaced; a layer is added. Of the living Gentoo derivatives it is the closest in posture to what Sabayon was.

Calculate Linux. Calculate Linux · Shipping · verified 2026-08-04 Calculate has run per-flavour binary repositories with a cl-update front end since long before Gentoo had a binhost, aimed at organisational deployment rather than at desktop convenience. Its news page carries nothing newer than 9 November 2019 and now redirects to a host called old.calculate-linux.org, which is the kind of thing that gets a distribution declared dead by people who stop looking there; its release mirror was publishing dated ISO directories as recently as 3 August 2026, the day before this piece was checked.

Read next. The comparison this piece deliberately does not make — which living system to install if you want what Sabayon gave you — is The five candidates for “Sabayon in 2026”. For how the project that made this argument actually ended, with a date on every step, see What happened to Sabayon Linux. The status of every distribution named above is in The Register.