unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Tomáš Čech" <sleep_walker@gnu.org>
To: guix-devel@gnu.org
Subject: Re: reproducible builds and debugging information
Date: Fri, 27 Mar 2015 22:55:46 +0100	[thread overview]
Message-ID: <20150327215546.GJ19723@venom.suse.cz> (raw)
In-Reply-To: <87619m9lrt.fsf@gnu.org>

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

On Fri, Mar 27, 2015 at 10:24:22PM +0100, Ludovic Courtès wrote:
>Tomáš Čech <sleep_walker@gnu.org> 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 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.

Thanks,

S_W

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

  reply	other threads:[~2015-03-27 21:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-22 17:26 reproducible builds and debugging information Tomáš Čech
2015-03-24 21:09 ` Ludovic Courtès
2015-03-25  0:33   ` Tomáš Čech
2015-03-26 21:21     ` Ludovic Courtès
2015-03-26 21:51       ` Tomáš Čech
2015-03-27 21:24         ` Ludovic Courtès
2015-03-27 21:55           ` Tomáš Čech [this message]
2015-03-28 17:41             ` Ludovic Courtès
2015-03-29 17:24               ` Mark H Weaver
2015-03-30 19:42                 ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150327215546.GJ19723@venom.suse.cz \
    --to=sleep_walker@gnu.org \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).