[rb-general] SOURCE_PREFIX_MAP and Occam's Razor

[Ximin Luo]

John Gilmore:
>> [..]
> 
> If the build-path was only put into the binaries UPON REQUEST, then
> the bulk of those packages would become reproducible.
> 
> [..]
> 
>> I also don't fancy trying to convince all build tools in existence
>> to adopt the information-stripping approach.
> 
> First, isn't the SOURCE_PREFIX_MAP an information-stripping approach
> itself?  It strips out PART of the path in the object file.  If you
> can't convince tool maintainers to strip information, you'll have a
> hard time getting uptake on SOURCE_PREFIX_MAP.  Whereas if they are
> amenable to stripping SOME information, I am merely suggesting a
> simpler and more straightforward change: stripping out the ENTIRE path
> (by default), and using a standard command line option when that path
> is actually needed.
> 
> Second, aren't the vast bulk of packages built by the GNU compiler
> tools?  A small patch to gcc that would remove the build-path by
> default would reduce the "build-path" issue to a much smaller, more
> tractable number of packages.
> 
> I was initially thinking that the compiler command-line option would
> have no argument, and if present would lead to the current behavior
> (object files contining the build path from the root).  This would
> avoid any issue about command line options being stored in object
> files.  But upon reflection, suppose it took an argument that was a
> relative path to the top of the source tree?  E.g.
> 
>   gcc --record-build-path-from=../../
> 
> [..]
> 

__FILE__, also -g is already "not the default". Of course you're welcome to follow up the rest of your suggestion with the GNU folks; but at this point I have spent so much time of this topic that I am getting a little bit tired of explaining to everyone "why not this way, why not that way".

>> Once this
>> SOURCE_PREFIX_MAP thing is done, it's done and everyone is happy.
> 
> Well, that's true for any solution.  Once it's solved, it's solved.
> But that begs the question of HOW to solve it.
> 
> There doesn't seem to be a consensus on how to get it done.  [..]
> 

There's never a perfect consensus, we have rough consensus.

>> It was a similar situation with SOURCE_DATE_EPOCH, the "hardcode"
>> "keep-it-simple" people didn't see the point but now it's all fine
>> and people with opinions across the whole range of the spectrum can
>> mostly agree to it.
> 
> The "hardcode" people didn't need to even look at SOURCE_DATE_EPOCH,
> since their tools already didn't encode a timestamp in the object
> files.
> 

They still need SOURCE_DATE_EPOCH for builds that take a variable amount of time and who put in a timestamp at the end of build.

> At Cygnus in the 1990s we made the GNU tools fully reproducible, even
> for cross-compilation.  This required dealing with many byte-order
> issues and floating-point representations and such -- a set of issues
> that you don't have.  We built the byte-order-independent BFD tools,
> and the new GNU linker, pretty much from scratch, for just that purpose.
> 
> [..]

Do you have this documented in detail somewhere? There is a difference between 100% reproducible and 92% reproducible. We are covering the final few %, so forgive me that I am not interested in people who claim their stuff is "reproducible" but actually do need things like SOURCE_DATE_EPOCH in corner cases that they didn't think about because they were too busy telling everyone how they set timestamps to 0 everywhere.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git