David Craven <da...@craven.ch> skribis:
> * gnu/system/file-systems.scm (spec->file-system): Remove variable.
> * gnu/system/linux-container.scm (container-script): Refactor.
[...]
> --- a/gnu/system/linux-container.scm
> +++ b/gnu/system/linux-container.scm
> @@ -81,8 +81,7 @@ MAPPINGS is a list of <file-system> objects that specify
> the files/directories
> that will be shared with the host system."
> (let* ((os (containerized-operating-system os mappings))
> (file-systems (filter file-system-needed-for-boot?
> - (operating-system-file-systems os)))
> - (specs (map file-system->spec file-systems)))
> + (operating-system-file-systems os))))
>
> (mlet* %store-monad ((os-drv (operating-system-derivation
> os
> @@ -94,10 +93,9 @@ that will be shared with the host system."
> (gnu build linux-container)))
> #~(begin
> (use-modules (gnu build linux-container)
> - (gnu system file-systems) ;spec->file-system
> (guix build utils))
>
> - (call-with-container (map spec->file-system '#$specs)
> + (call-with-container #$file-systems
AFAICS that doesn’t work because <file-system> and records in general
are not automatically marshalled/unmarshalled when staging code. Thus,
the above would leave to an invalid on-disk s-expression like this:
(begin
(use-modules …)
(call-with-container (#<<file-system> …> #<<file-system> …>)
…))
Manually calling ‘file-system->spec’ on the host side, and then
‘spec->file-system’ on the build side is a way to explicitly
marshall/unmarshall the record (I mentioned it as a current limitation
of gexps in my Scheme Workshop talk).
Makes sense?
Thanks,
Ludo’.
