Let me give you the simplest example, when builds are reproducible you don't need package repositories, you need build caches.
All the problems with maintaining a repository (save bandwidth) evaporate.
The type of reproducibility is different here. What you mention is possible via a stable compiler ABI already. However one needs to keep the source code the same. Without a stable compiler ABI, you may or may not fix it depending on what the compiler does.
The goal of reproducible builds is removing sources of environment-dependent behavior at the build level instead of the compiler level. So given all the same dependencies and same build commands your binaries should match wherever and whenever you compile them. The distros and software developers also made a huge effort to remove any kind of environment-dependent commands.
Different distros still have differences in the build commands they issue and the set of dependencies they enable. The space to cache each individual possible output would be enormous and impractical. So you would still need repositories.
https://discourse.nixos.org/t/the-nixos-foundations-call-to-...
It is absolutely better to remove build entropy at the source code stage, but until all software is written that way there are a few build-environment tricks we can use along the way.
Meanwhile I enjoy setting up my own GNU Guile projects with a Makefile that sets up a reproducible Guix shell in which my project is run, so that I get the same result on various devices, only needing to issue a single easily memorized or discoverable Makefile target call. Most developers I met don't know how to set something like this up. Provided no one messes with guix package manager commits and guix infrastructure still exists, my projects will run in 10y just like they do today, with reproducible result. Neat.
Recently I have taken some time to have this for Ocaml as well. Took some asking on the mailing list, but now works. No need to have anything installed prior to running the Makefile target other than Make and Guix package manager.
Edit: Worth looking at https://github.com/numtide/devshell
And I did. He was a developer of a purported secure messaging app. The question that changed his mind was: "How are your users, who surely audited your sources and found no trojans hiding there, going to know that you are not distributing trojaned official binary builds?"
Unfortunately, Nix and Guix are trying to work around the issue by warping the whole world around toolchains that were never built with reproducability in mind. So many tool chains just download executables and run them as part of the build process - NPM packages do this, Android app build process does this, Rust packages do this. Turing completeness is too good to give up and gives people the freedom to deploy sloppy solutions.
Debian has .buildinfo files over at https://buildinfos.debian.net/ referencing files on https://snapshot.debian.org/.
This is not special to NixOS, documented and archived build environments are an essential part of accomplishing reproducible builds for an operating system.
I've been using Gentoo for the past few weeks and this was my thought. There are so many ways to compile packages depending on your needs. It is practical to make binary sets for a few common configurations that are good enough for most people for each distro, though.
(Installing and using Gentoo has been an incredible learning experience. You have to go into it with the desire to take long tangents filling the gaps in your knowledge re: shared libraries, kernel modules, your init system of choice, gcc, your windowing system of choice, bootloaders, bash, etc. I feel like I've made more of a quantum leap in my Linux skills the past month than I have in years, and it's been quite fun and rewarding.)
> Different distros still have differences in the build commands they issue and the set of dependencies they enable.
Would it even make sense in theory for this not to be the case? What is a Linux distro but a set of programs, libraries, and environment choices chosen to be run on the Linux kernel?
Seems like Yocto would make the base for a good general purpose desktop distro (if there is not one out there already.)
Stagex + Yocto would be fully reproducible from a small seed.
> Yocto would make the base for a good general purpose desktop distro
YP has been working on a public binary reference cache/distro.
OE recipe-grade concision! This summary belongs in YP docs, wikipedia and LLM IDE warnings.
It certainly doesn't change the nature of packaging in any real way in that case.
1. If the deps are also themselves reproducible then you refer to a fixed point version of them and (at least for nix) the package manager works out the rest.
2. Signatures are a trust mechanism, if a cache feeds you bad data in response to a query then that's absolutely an issue, but since there can be multiple caches (or your own local spot-checks) it becomes easier to detect if a cache is returning bad data. A hyper-targetted attack would still get you unless you decide to manually build certain packages, but that's no different than existing repos.
Manually building might sound impractical but it doesn't actually take that long, probably less than a day for a desktop environment, which might acceptable in a high-trust environment if amortized. I should add that the process is fully automatic, it just takes longer than using a cache.
3. Moderation I don't have a good answer to, anyone can run an apt server, or publish a flake.nix file to a repo. Some would say it is censorship resistant.
Build reproducibility has other values, like the virtue of basic determinism. That answers the question of why would we want to reproduce a build?
If you /can't/ build the exact same thing twice, down to the bit, how do you know that, say, a compiler isn't doing something funny based on an uninitialized variable?
To check reproducible builds against regression, we can't always be caching. Someone has to actually build everything at least twice (ideally more times) and verify that they match. And this has to be done forever; if you don't build multiple times and check, you will not catch a regression in reproducibility.