civodul pushed a commit to branch master
in repository guix-artwork.

commit fe3bca07e5901fcd69ad5fbd45a30af45de99ff8
Author: Ludovic Courtès <>
Date:   Wed May 16 10:59:45 2018 +0200

    website: Add post about 'guix pack -R'.
    * website/posts/ New file.
 website/posts/ | 177 +++++++++++++++++++++++++++++++++
 1 file changed, 177 insertions(+)

diff --git a/website/posts/ 
new file mode 100644
index 0000000..a0b1c0d
--- /dev/null
+++ b/website/posts/
@@ -0,0 +1,177 @@
+title: Tarballs, the ultimate container image format
+date: 2018-05-16 11:00
+author: Ludovic Courtès
+tags: Containers, Software development
+A year ago [we introduced `guix
+a tool that allows you to create “application bundles” from a set of Guix
+package definitions.  On your Guix machine, you run:
+guix pack -S /opt/gnu/bin=bin guile gnutls guile-json
+and you get a tarball containing your favorite programming language
+implementation and a couple of libraries, where `/opt/gnu/bin` is a
+symlink to the `bin` directory containing, in this case, the `guile`
+command.  Add `-f docker` and, instead of a tarball, you get an image in
+the Docker format that you can pass to `docker load` on any machine
+where Docker is installed.  Overall that’s a relatively easy way to
+share software stacks with machines that do not run Guix.
+The tarball format is plain and simple, it’s the one we know and love,
+and it’s been there “forever” [as its name
+The tarball that `guix pack` produces can be readily extracted on
+another machine, one that doesn’t run Guix, and you’re done.  The
+problem though, is that you’ll need to either unpack the tarball in the
+root file system or to play tricks with the `unshare` command, as we saw
+[in the previous
+Why can’t we just extract such a tarball in our home directory and
+directly run `./opt/gnu/bin/guile` for instance?
+# Relocatable packages
+The main issue is that, except in the uncommon case where developers
+went to great lengths to make it possible (as with
+[GUB](, see the [`*-reloc*.patch`
+files](, packages
+built for GNU/Linux are not relocatable.  ELF files embed things like
+the absolute file name of the dynamic linker, directories where
+libraries are to be search for (they can be relative file names with
+`$ORIGIN` but usually aren’t), and so on; furthermore, it’s very common
+to embed things like the name of the directory that contains locale data
+or other application-specific data.  For Guix-built software, all these
+are absolute file names under `/gnu/store` so Guix-built binaries won’t
+run unless those `/gnu/store` files exist.
+On machines where support for [“user
+is enabled, we can easily “map” the directory where users unpacked the
+tarball that `guix pack` produced to `/gnu/store`, as shown in the
+previous post:
+$ tar xf /path/to/pack.tar.gz
+$ unshare -mrf chroot . /opt/gnu/bin/guile --version
+guile (GNU Guile) 2.2.0
+It does the job but remains quite tedious.  Can’t we automate that?
+# `guix pack --relocatable`
+The `--relocatable` (or `-R`) option of `guix pack`, which landed [a few
+days ago](, produces tarballs with
+automatically relocatable binaries.  Back to our earlier example, let’s
+say you produce a tarball with this new option:
+guix pack --relocatable -S /bin=bin -S /etc=etc guile gnutls guile-json
+You can send the resulting tarball to any machine that runs the kernel
+Linux (it [doesn’t even have to be
+with user namespace support—which, unfortunately, is disabled by default
+on some distros.  There, as a regular user, you can run:
+$ tar xf /path/to/pack.tar.gz
+$ source ./etc/profile    # define ’GUILE_LOAD_PATH’, etc.
+$ ./bin/guile
+guile: warning: failed to install locale
+GNU Guile 2.2.3
+Copyright (C) 1995-2017 Free Software Foundation, Inc.
+Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
+This program is free software, and you are welcome to redistribute it
+under certain conditions; type `,show c' for details.
+Enter `,help' for help.
+scheme@(guile-user)> ,use(json)
+scheme@(guile-user)> ,use(gnutls)
+We were able to run Guile and to use our Guile libraries since sourcing
+`./etc/profile` augmented the `GUILE_LOAD_PATH` environment variable
+that tells Guile where to look for libraries.  Indeed we can see it by
+inspecting the value of `%load-path` at the Guile prompt:
+scheme@(guile-user)> %load-path
+$1 = 
+Wait, it’s all `/gnu/store`!  As it turns out, `guix pack --relocatable`
+created a wrapper around `guile` that populates `/gnu/store` in the
+mount namespace of the process.  Even though `/gnu/store` does not exist
+on that machine, our `guile` process “sees” our packages under
+scheme@(guile-user)> ,use(ice-9 ftw)
+scheme@(guile-user)> (scandir "/gnu/store")
+$2 = ("." ".." "0249nw8c7z626fw1fayacm160fpd543k-guile-json-0.6.0R" 
"5kih0kxmipzjw10c5 [...]
+The wrapper is a small statically-linked [C
+(Scheme would be nice and would allow us to reuse
+but it would also take up more space.)  All it does is create a child
+process with separate mount and user namespaces, which in turn mounts
+the tarball’s `/gnu/store` to `/gnu/store`, bind-mounts other entries
+from the host root file system, and `chroot`s into that.  The result is
+a binary that sees everything a “normal” program sees on the host, but
+with the addition of `/gnu/store`, with minimal startup overhead.
+In a way, it’s a bit of a hack: for example, what gets bind-mounted in
+the mount namespace of the wrapped program is hard-coded, which is OK,
+but some flexibility would be welcome (things like Flatpak’s [sandbox
+for instance).  Still, that it Just Works is a pretty cool feature.
+# Tarballs vs. Snap, Flatpak, Docker, & co.
+Come to think of it: if you’re a developer, `guix pack` is probably
+one of the easiest ways to create an “application bundle” to share with
+your users; and as a user, these relocatable tarballs are about the
+simplest thing you can deal with since you don’t need anything but
+`tar`—well, and user namespace support.  Plus, since they are
+anyone can rebuild them to ensure they [do not contain
+malware]( or to
+[check the provenance and licensing of its
+Application bundles cannot replace full-blown package management, which
+allows users to upgrade, get security updates, use storage and memory
+efficiently, and so on.  For the purposes of quickly sharing packages
+with users or with Guix-less machines, though, you might find Guix packs
+to be more convenient than Snap, Flatplak, or Docker.  Give it a spin
+and [let us know](!
+#### About GNU Guix
+[GNU Guix]( is a transactional package
+manager for the GNU system.  The Guix System Distribution or GuixSD is
+an advanced distribution of the GNU system that relies on GNU Guix and
+[respects the user's
+In addition to standard package management features, Guix supports
+transactional upgrades and roll-backs, unprivileged package management,
+per-user profiles, and garbage collection.  Guix uses low-level
+mechanisms from the Nix package manager, except that packages are
+defined as native [Guile]( modules,
+using extensions to the [Scheme]( language.  GuixSD
+offers a declarative approach to operating system configuration
+management, and is highly customizable and hackable.
+GuixSD can be used on an i686, x86_64 and armv7 machines.  It is also
+possible to use Guix on top of an already installed GNU/Linux system,
+including on mips64el and aarch64.

Reply via email to