[Top][All Lists]

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

Re: ‘guix publish’ now compresses archives

From: Tomáš Čech
Subject: Re: ‘guix publish’ now compresses archives
Date: Wed, 20 Jul 2016 15:05:59 +0200
User-agent: Mutt/1.6.1-neo (2016-06-11)

On Wed, Jul 20, 2016 at 01:20:26PM +0200, Ricardo Wurmus wrote:

Tomáš Čech <address@hidden> writes:

On Tue, Jul 19, 2016 at 04:23:14PM +0200, Ricardo Wurmus wrote:

Tomáš Čech <address@hidden> writes:

Imagine situation where person A is running some distribution with
Guix package manager on top and has some set of his personal packages
containing additional patches which are not part of Guix GIT.

He'd like to share the package with person B, running different
distribution with Guix package manager at different revision on top,
with different set of personal packages and alterations.

I'd like to provide them a way, how to pass from person A to person B
some binary archive in a way that he could understand (and verify)
what he received. If it requries out-of-tree package definitions of
person A, patches, etc, bundle it together.

This is already possible with “guix archive --export” and “--import”.
What’s not so nice about this is that you can end up with binaries in
your store that you cannot rebuild yourself (because you never had the
sources to begin with).  (I wonder if this has implications on software

~~ Ricardo

Ooops, I answered to Ricardo only...

Yes, you can take exported archive (optionally with it's dependencies
- --recursive) and add it to the person B's store. That is comparable
to tarball (and making Guix aware of new items in store).

The thing that you can't rebuild the binaries is exactly my point,
because person A knows how to build it, but person B does not. Thanks!

Are you suggesting that package archives and store exports must include
all package expressions (and all supporting code to build them) needed
to reproduce them?  The store can hold packages that were built with
different versions of Guix.  Does this mean that each version of Guix
that has been used should also be kept in the store?

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.

Now, as long as Guix sources are part of equation and change during
the time, you may need to keep more Guix versions. If there is some
stable not-changing core, you probably could eliminate the need.

But wait, this goes even further than just versions of Guix.  There may
be stuff in the GUIX_PACKAGE_PATH.  Are you suggesting that all of this
should become part of package archives?

This doesn't sound like tougher problem than the rest - you have
separate package definitions. It means just more data to process.
(that doesn't mean that problem is easy to solve)

If so: how?

1] I guess I should better explain my position. In the discussion on
social media I was explaining why it can't be used now for
self-containing packages and what is missing. My goal now on the
mailing list is here the discussion itself, to see whether it is
possible and whether are people interested in that.

2] I don't know much Guile, maybe there is nice way how to work with
Scheme program from Scheme program. If I should implement it, I'd need
to strictly "draw line" between package definitions and Guix itself,
then I would need to parse package definitions files to identify which
parts were used and ship those. Maybe you can get this information
during evaluation by some side effect. I don't know Guile enough, really.


Attachment: signature.asc
Description: Digital signature

reply via email to

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