On Fri, May 29, 2020 at 01:56:28PM -0400, Stephen Scheck wrote: > > > "guix-system$|guix-packages-base$|guix-[0-9a-f]*-modules$" > > [...] > > > 191M > > /gnu/store/l3amdz5xyhflg5wdzlxr2685dq5glic2-guix-527ab3125-modules > > > 201M > > /gnu/store/5mhn1ynxvy7jihsknsnv3yspkkvc0r5s-guix-2e59ae238-modules > > > > If I understand correctly, you should not need both of these directories > > in a Guix VM image. The latter hashes are truncated guix.git commit > > hashes and a VM image would only be based on a single one. > > > > Exactly, I agree (to the extent that I understand Guix). > > I recommend looking into why all these directories are being copied into > > your images. > > > > Whatever is in /gnu/store (as managed by Guix) goes into the image, nothing > more and nothing less.
Okay. For debugging, can you try garbage collecting those modules directories? And if the garbage collector refuses, you can investigate why with the 3 R's of Guix garbage collection, --referrers, --references, and --requisites. > How else would you suggest that it be done? It would be nice if `guix > system docker-image` > took `--branch` and `--commit` options to build a container from a > well-defined Guix check-in > state, but that doesn't seem to be the case. And in any case - too slow. > The point here is to > leverage daily incremental pulls to keep data transfer and build times down. --branch and --commit would be passed to `guix pull`, and then you'd run `guix system docker-image` based on that.
