l...@gnu.org (Ludovic Courtès) writes: > [large snip] > > I hope this clarifies things.
Yes! Thanks for your patience. It now dawns on me that our primary aim isn't byte-equal build process outputs (in terms of file contents); it's "immutable run-time behavior" of a package. That is to say, if /gnu/store/...-foo/bin/foo works fine today, it should work fine any day; it's unacceptable to let it load a different .so than its designated one, unless we define some very strict criteria for the .so and prove that a replacement satisfies them... Similarly for some Python module the program uses. I was chasing a "reproducible builds" red herring. That being said, I still think it's wasteful that C code gets recompiled when there's an update to a dynamic component. A rough idea for the future: save some intermediate build output (say from the 'build' phase), then when there's an update to a run-time component such as a DSO or dynlang module, make a new package that merely receives some tweaks to the saved intermediate output, such as fixing RUNPATH, re-patching shebang lines, etc. Users will still need to download these new packages; that in turn could be improved via binary diffs one day. > So, where were we with this nmap patch? :-) Heh, indeed. I thought I'd wait for feedback from the Nmap ML but I guess that's not necessary. I'll continue working on it tomorrow. Taylan
