From: "Thompson, David" <dthompson2@worcester.edu>
To: Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: ‘guix publish’ now compresses archives
Date: Thu, 21 Jul 2016 11:58:34 -0400 [thread overview]
Message-ID: <CAJ=RwfbZrcbQ7RvN3aYXWB6_PCxLgjddFX-o8Y5n2HpdMPE72w@mail.gmail.com> (raw)
In-Reply-To: <87shv3eese.fsf@mdc-berlin.de>
On Thu, Jul 21, 2016 at 1:33 AM, Ricardo Wurmus
<ricardo.wurmus@mdc-berlin.de> wrote:
>
> Thompson, David <dthompson2@worcester.edu> writes:
>
>> On Wed, Jul 20, 2016 at 9:05 AM, Tomáš Čech <sleep_walker@gnu.org> wrote:
>>
>>> First, I'm not saying that we should do that for every archive, but I
>>> think that having a way how to automatically export this information
>>> would be great and I see it as a week point for using Guix packages as
>>> alternative to Snappy or Flatpak.
>>
>> I don't really understand the point of this back-and-forth. It's
>> quite simple: If the user builds the same package expression with the
>> same version of Guix, they will get the same result if the build is
>> deterministic. I don't understand the contrast with Snappy and
>> Flatpak because they don't provide this feature at all, opting instead
>> to provide opaque binaries with no real provenance. I can only assume
>> that there is some fundamental misunderstanding about Guix going on
>> here.
>
> The point is that exporting a store item (or a package closure) is the
> moral equivalent to producing an opaque binary. The claim is that Guix
> could do better here. I agree to the first part but I’m not sure about
> the second part. It would be very nice if Guix really *could* do better
> here without having to embed a copy of itself to each exported package.
Derivations are purposely a one-way street. There's *no* way to get
from the derivation back to the source. You always want to go from
the source to the derivation. I think we're asking the wrong question
here. It's not "I have a binary, now where is the source?", it's "I
have the source, now is there a binary available?"
- Dave
next prev parent reply other threads:[~2016-07-21 15:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-18 22:22 ‘guix publish’ now compresses archives Ludovic Courtès
2016-07-19 6:29 ` Tomáš Čech
2016-07-19 10:03 ` Pjotr Prins
2016-07-19 13:15 ` Ludovic Courtès
2016-07-19 13:42 ` Tomáš Čech
2016-07-19 14:23 ` Ricardo Wurmus
2016-07-19 15:50 ` Tomáš Čech
2016-07-20 11:20 ` Ricardo Wurmus
2016-07-20 13:05 ` Tomáš Čech
2016-07-20 13:12 ` Thompson, David
2016-07-20 16:10 ` Tomáš Čech
2016-07-21 5:33 ` Ricardo Wurmus
2016-07-21 15:58 ` Thompson, David [this message]
2016-07-21 5:53 ` Ricardo Wurmus
2016-07-21 20:50 ` Tomáš Čech
2016-07-21 10:12 ` Andy Wingo
2016-07-21 12:43 ` 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='CAJ=RwfbZrcbQ7RvN3aYXWB6_PCxLgjddFX-o8Y5n2HpdMPE72w@mail.gmail.com' \
--to=dthompson2@worcester.edu \
--cc=guix-devel@gnu.org \
--cc=ricardo.wurmus@mdc-berlin.de \
/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).