[bug#30572] [PATCH 0/7] Add "guix system docker-image" command (v2)

[Chris Marusich]

Hi Danny and Ludo,

Thank you for the feedback!  Please find attached a new patch series,
which incorporates all the feedback I've received so far.  I've verified
the following:

* This new patch series applies cleanly to b4bf9516.

* For every patch in this new series, "make" succeeds and "make check"
  succeeds for the relevant tests: guix-system.sh, guix-pack.sh (when it
  exists), pack.scm, and system.scm.

* After applying all patches, there are no new test failures for both
  "make check" and "make check-system"; the tests which passed before
  continue to pass.  However, note that there are some existing
  unrelated failures for both targets as of commit b4bf9516.  I will
  open a bug report for those unrelated failures shortly.

* I built a GuixSD Docker image from the example file docker-image.tmpl,
  loaded it into Docker on another machine, and successfully installed
  and ran GNU Hello via Guix in the Docker container.

Some notable differences from the first patch series are as follows:

* There is no longer any need to modify base-initrd or raw-initrd.  To
  work around the dlopen problem, we use a workaround like the one Ludo
  suggested.

* The --bootstrap option (and tests) for "guix pack" are improved.  The
  new option will cause "guix pack" to use not just the bootstrap Guile,
  but also the bootstrap tar and xz.

* When building in a VM, share a temporary directory by default.  This
  solves the problem of limited space in /tmp in the VM.

* Rewrite build-docker-image significantly to allow adding more paths.

The rest is largely the same.  Please let me know what you think.  I
still have the following questions from my original email:

* In system-docker-image (gnu/system/vm.scm), why is it necessary to
  define a custom (guix config) module?  I copied some of the logic
  from docker-image (guix/scripts/pack.scm), and it works, but I do
  not understand this part.

* Similarly, in gnu/system/vm.scm, why do we autoload libgcrypt?  I do
  not understand why we cannot simply #:use-module (gnu packages
  gnupg) like we do with all the other modules here.  Is it just for
  improved performance?

* Similarly, in gnu/system/vm.scm, why do we use (ungexp-native json)?
  In the code, this is #+json and it occurs close to the comment
  "Guile-JSON is required by (guix docker)."  It seems to me like we
  often mix the use of ugexp and ungexp-native for no apparent reason,
  and that in many cases it doesn't matter which one we use.

If anyone can answer those questions, I'd really appreciate it!

Chris Marusich (7):
  gnu: bootstrap: Add trivial packages for bash, mkdir, tar, and xz.
  tests: Add tests for "guix pack".
  vm: Allow control of deduplication in root-partition-initializer.
  gnu: When building in a VM, share a temporary directory.
  guix: Rewrite build-docker-image to allow more paths.
  system: Add "guix system docker-image" command.
  tests: Add tests for "guix system disk-image" et al.

 Makefile.am                           |   1 +
 doc/guix.texi                         |  42 ++++++-
 gnu/build/vm.scm                      |  20 +++-
 gnu/packages/bootstrap.scm            |  34 ++++++
 gnu/packages/package-management.scm   |   2 +
 gnu/system/examples/docker-image.tmpl |  47 ++++++++
 gnu/system/vm.scm                     | 125 ++++++++++++++++++++-
 guix/docker.scm                       | 200 +++++++++++++++++++++-------------
 guix/scripts/pack.scm                 |  70 ++++++++----
 guix/scripts/system.scm               |  12 +-
 tests/guix-pack.sh                    |  74 +++++++++++++
 tests/guix-system.sh                  |  17 +++
 12 files changed, 531 insertions(+), 113 deletions(-)
 create mode 100644 gnu/system/examples/docker-image.tmpl
 create mode 100644 tests/guix-pack.sh

-- 
2.15.1