Re: reproducible builds and debugging information

["Tomáš Čech" <sleep_walker@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 2749 bytes --]

On Thu, Mar 26, 2015 at 10:21:35PM +0100, Ludovic Courtès wrote:
>Tomáš Čech <sleep_walker@gnu.org> skribis:
>
>> On Tue, Mar 24, 2015 at 10:09:50PM +0100, Ludovic Courtès wrote:
>
>[...]
>
>>>Packages that have an autoconf-based build system, and I suppose most
>>>others, are built with -g.
>>
>> I can't confirm this statement.
>>
>> I added "debug" output to curl package:
>
>Indeed, I just checked and cURL overrides the default behavior.  Here it
>has to be configured with --enable-debug, which also enables the test
>suite (!).  Do you want to try that, and add the “debug” output?
>
>>>The binaries get stripped by default and
>>>debugging info is lost unless the package has a “debug” output.
>>
>> OK, the difference -g and -ggdb is slight, but there is the problem
>> with "debug" output.
>>
>> When package has output "debug" always - there is no problem.
>>
>> When package doesn't have "debug" output and I need it, mere adding
>> output "debug" into package receipt will change the hash so I'll get
>> different package.
>
>Right.
>
>>>Currently a few key packages have that, but most don’t (I think Debian
>>>does something similar, not sure about other distros.)
>>
>> 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?

>>>We could make it opt-out rather than opt-in, but the issue is disk usage
>>>on build machine (including end-user machines.)  See
>>><http://lists.gnu.org/archive/html/bug-guix/2013-07/msg00015.html>.
>>>
>>>Thoughts?
>>
>> If we have distribution of reproducible packages, we can keep it
>> opt-in and generate debug information next time (by not dropping
>> it).
>
>That’s not how it works; generating the debug info requires redoing the
>whole build process, but with a slight difference.

I know, I was ambiguous again. We both meant the same.

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.

Then someone reports bug, delivers coredump from some crash.
You need debug info for analysis - you prevent from automatic
deletion of the store with debug information.


S_W



[-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --]