[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ‘guix publish’ now compresses archives

From: Thompson, David
Subject: Re: ‘guix publish’ now compresses archives
Date: Thu, 21 Jul 2016 11:58:34 -0400

On Thu, Jul 21, 2016 at 1:33 AM, Ricardo Wurmus
<address@hidden> wrote:
> Thompson, David <address@hidden> writes:
>> On Wed, Jul 20, 2016 at 9:05 AM, Tomáš Čech <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]