This is one of the "costs" of reproducible builds, just like the requirement to use pre-configured seeds for pseudo random number generators etc. It does hit r

This is one of the "costs" of reproducible builds, just like the requirement to use pre-configured seeds for pseudo random number generators etc. It does hit real projects and may be part of the reason that "99%" is called out but Fedora also mentions that they can't match the official reproducible-builds.org meaning in the above just due to how RPMs work, so we will see what other constraints they have to loosen. Here is one example of where suse had to re-enable it for gzip. https://build.opensuse.org/request/show/499887 https://build.opensuse.org/request/show/499887 Here is a thread on PGO from the reproducible-builds mail list. https://lists.reproducible-builds.org/pipermail/rb-general/2022-June/002633.html https://lists.reproducible-builds.org/pipermail/rb-general/2... There are other costs like needing to get rid of parallel builds for some projects that make many people loosen the official constraints. The value of PGO+LTO being one. gcda profiles are unreproducible, but the code they produce is typically the same. If you look into the pipeline of some projects, they just delete the gcda output and then often try a rebuild if the code is different or other methods. While there are no ideal solutions, one that seems to work fairly well, assuming the upstream is doing reproducible builds, is to vendor the code, build a reproducible build to validate that vendored code, then enable optimizations. But I get that not everyone agrees that the value of reproducibility is primarily avoiding attacks on build infrastructure. However reproducible builds as nothing to do with MSO model checking etc... like some have claimed. Much of it is just deleting non-deterministic data as you can see here with debian, which fedora copied. https://salsa.debian.org/reproducible-builds/strip-nondeterminism https://salsa.debian.org/reproducible-builds/strip-nondeterm... As increasing the granularity of address-space randomization at compile and link time is easier than at the start of program execution, obviously there will be a cost (that is more than paid for by reducing supply chain risks IMHO) of reduced entropy for address randomization and thus does increase the risk of ROP style attacks. Regaining that entropy at compile and link time, if it is practical to recompile packages or vendor, may be worth the effort in some situations, probably best to do real PGO at that time too IMHO.