Re: reproducible builds and debugging information

[Ludovic Courtès]

Tomáš Čech <address@hidden> skribis:

> On Fri, Mar 27, 2015 at 10:24:22PM +0100, Ludovic Courtès wrote:
>>Tomáš Čech <address@hidden> skribis:
>>
>>> On Thu, Mar 26, 2015 at 10:21:35PM +0100, Ludovic Courtès wrote:
>>
>>[...]
>>
>>>>> On openSUSE you have available all the subpackage providing stripped
>>>>> debug informations and subpackage providing source code from the
>>>>> moment of build (so DWARF information in debug part can match the source).
>>>>
>>>>You mean there’s a ‘-debug’ package for every single package?
>>>
>>> For every single binary package, yes. You can suppress it too. Why it
>>> is so surprising?
>>
>>It’s just that I didn’t know, and my recollection is that Debian doesn’t
>>have -dbg packages for every package.
>>
>>> I would like to move the decision whether to keep or to drop debug
>>> information outside of the build itself to keep the hash the same.
>>>
>>> Imagine situation where you added "debug" output to every package and
>>> after each build the newly generated store with debug information is
>>> deleted (carefully, not to corrupt database, of course). Your hash
>>> still will be the same.
>>
>>I see what you mean, but again, that’s not how it works, and I would
>>argue that it’s not desirable.
>
> Yes, I know that it works differently now - that was the reason I
> initiated this thread. If you considered this option and refused it,
> I'm fine with that. Different distributions set different goals. I'd
> like to hear the arguments against the general idea sometime but lets
> not waste more time on this topic.

To be clear: I’m not rejecting the idea of having debugging symbols for
everything.  What I’m saying here is that there are deep design choices
that make it impossible to just “make a debug package and keep the hash
unchanged.”

A key design idea of Nix and Guix is that the store file name contains a
hash of all the inputs of the build process that led to this store item
(info "(guix) Introduction").  “All the inputs” really means everything,
including build scripts and command-line options.  Obviously the
processes that keep debugging symbols does different things from the one
that discards them, so it has a different hash.

This is really at the core of the design and I think it’s a strength.  I
don’t think this specific use case would justify changing it, esp. since
we can achieve basically the same goal differently.

I hope this clarifies the discussion.

>>To move forward, a possible action would be to try to have ‘outputs’
>>default to '("out" "debug") and see (1) how much breaks, and (2) how
>>much space.
>>
>>Would you like to give it a try?
>
> Good idea, yes. I'll do that.

Cool, thank you!

Ludo’.