Re: Guix Docker image inflation

[Leo Famulari]

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.