Re: ‘guix publish’ now compresses archives

[Ricardo Wurmus]

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.

One way to do that is to provide the equivalent of a source package,
i.e. exporting not only the closure but everything that’s needed to
build it yourself (including the source archives of all involved
packages and all package expressions and all of the supporting Guix
library features).

The weaker proposition is to embed some metadata (such as the exact
version of Guix upstream and a list of packages, but this would not be
sufficient as Guix can be modified and GUIX_PACKAGE_PATH would not be
included).

~~ Ricardo