[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: Tue, 19 Jul 2016 08:29:15 +0200
User-agent: Mutt/1.6.1-neo (2016-06-11)

On Tue, Jul 19, 2016 at 12:22:42AM +0200, Ludovic Courtès wrote:

‘guix publish --compression’ can now compress archives in gzip format,
using zlib, which makes it much more usable in real life.  See commit

‘guix publish’ is cache-friendly: it uses /nar/gzip URLs for gzipped
archives, and /nar for uncompressed archives.  That way, even if ‘guix
publish’ is restarted with different compression parameters, previously
announced /nar/* URLs remain valid.

Please try it and report back.

To recap, the difficulty with all this is that we couldn’t just call out
the ‘gzip’ command because ‘guix publish’ uses threads, and threads and
fork(2) don’t go together well.  So we needed zlib bindings, and when
discussing it earlier with Dave, I thought we’d have to wrap zlib’s
low-level API, which is painful, so we were sad and all.  Next we had
this outage, which entailed more sadness.

Then I realized that zlib has this high-level ‘gz’ API, which is easy
and does what we need; hence, (guix zlib) provides bindings to that.
The only limitation is that it needs a file descriptor as its source or
sink and cannot compress into memory.  That’s enough for ‘guix publish’

Comments welcome!

When I saw archive improvement I remembered I have a comment about
that (but not associated to compression).

Recently when Snappy and Flatpak news flew around the world I saw some
people were thinking about Guix as possible and cleaner alternative to
new package types.

As I am happy to see enthusiasm about Guix, I don't think that current
archive format is usable for distribution of binary packages of
whatever origin. Problem is that we have package definition as part of
package manager GIT snapshot or local files but this information is
not distributed along with the package archive.

If this area is interesting for us, we can do better. It would be
great to be able to verify such archive, maintain the reproducibility
or provide recipe how to bake missing dependencies.

I was thinking that we could (and should) add some optional support
for metadata which could describe the origin of the package. It could
- Guix GIT revision used
- differences against GIT revision
- local package recipe
- exported dependency tree of package recipes
- optionally URL where missing dependencies can be found

What do you think?


Attachment: signature.asc
Description: Digital signature

reply via email to

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