Hi!
David Craven skribis:
> Ah yes, that makes sense. Thank you for explaining. I think I'm
> understanding the general design pattern better:
>
> Build side code that uses a record from gnu/system is a gexp in
> gnu/system. This gexp is passed to a function in gnu/build so that
> gnu/build itse
Hi Ludo,
Ah yes, that makes sense. Thank you for explaining. I think I'm
understanding the general design pattern better:
Build side code that uses a record from gnu/system is a gexp in
gnu/system. This gexp is passed to a function in gnu/build so that
gnu/build itself doesn't need to import gnu/
David Craven 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 objects tha
The reason I'm suggesting to remove this function, is because it seems
like any case one would want to use it, one should not be using it.
There is a separation of gnu/system and gnu/build and a
spec->file-system function encourages people to try using the
in the build part. I think that it's a "c
* gnu/system/file-systems.scm (spec->file-system): Remove variable.
* gnu/system/linux-container.scm (container-script): Refactor.
---
gnu/system/file-systems.scm| 11 ---
gnu/system/linux-container.scm | 6 ++
2 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/gnu/sy
