[filleokus]

> but I guess for a subset of users it means producing an identical binary.

Whenever I hear people talk about the problems of creating reproducible builds, I often hear stuff about timestamps or other metadata inserted by the compiler that would "break" the reproducibility (under the stricter definition).

Having your own source code versioned and dependencies version-pinned (and pretty high confidence that the dependency package foobar-1.12 stays the same over time) seem just like old fashioned "good practice".

The looser definition would imply that all versioned software without external dependencies (or the source of the dependencies manually included in the repository) is reproducible?

[elbear]

How many people pin the exact version of a system library they are using? Or of a binary used in the build process.

Also, how many people run the build in a sandbox to avoid "interference" from the environment?

Yes, this is all good practice, but I think very few people do it, because it's not easy.

[Foxboron]

> How many people pin the exact version of a system library they are using? Or of a binary used in the build process.

Linux distributions does. Both Debian and Arch Linux embed information about the entire build environment into the built package.

> Also, how many people run the build in a sandbox to avoid "interference" from the environment?

Most linux distributions does this.

[filleokus]

Yeah, true. I was thinking of doing release builds in containers via the CI/CD pipeline, keeps the environment pretty static, but not completely static of course.

But further: All of these things would still not be enough for the strictest definition (exact same binary), at least with normal compiler defaults afaik?

[yjftsjthsd-h]

> All of these things would still not be enough for the strictest definition (exact same binary), at least with normal compiler defaults afaik?

Right, because of things like timestamps getting into the binary.