It seems to me it would be the most reliable, future-proof, way, but might have the downside of making it a step harder for people without the special environment to reproduce the build.
I'm pretty new at looking under the hood of linux, but I can imagine these approaches at least:
- preload system library wrappers around key nondeterministic functions
- replace /dev/*random with fakes (could be named pipes, dummy devices fed by modules, or just flat files!)
- replace system libraries with fullblown libraries with nondeterministic calls rewritten (could merge changes upstream, provide a flag)
- create a kernel module which alters the behavior of the running kernel to be more deterministic
- change the kernel itself to have a "deterministic mode" (could merge upstream)
The goal of making packages deterministic would change from modifying the packages themselves, to modifying the build environment, with the hope of making a build environment that always creates deterministic builds for normal software packages. This should be very possible.
The approach of small library wrappers and/or replacing device files could be pretty fast to implement, but not as "far thinking" as the other end of the spectrum, where changes to glibc and linux could be merged upstream.