David Craven skribis:
> * gnu/build/activation.scm (activate-user): Make sure /var/lib exists.
^
AFAICS this is ‘activate-users+groups’.
I initially had the same reaction as 宋文武, but based on your reply, I
agree that it looks like the right place.
> + ;; allow /va
> And instead of handing this particular case,
> how about create any parent directory
> of HOME?
I briefly thought about it and thought that we should discourage users
to pick *any* home directory. This will prevent them from doing so.
But it's just an artificial restriction. In that case it's a
Vincent Legoll writes:
> Hello,
>
>> Also, it's better fit in the 'add-user' procudere, before
>> the run of `useradd' command. And instead of handing
>> this particular case, how about create any parent directory
>> of HOME? like:
>>
>> [...]
>> ;; create the parent directory of HOME.
>> (
Hello,
> Also, it's better fit in the 'add-user' procudere, before
> the run of `useradd' command. And instead of handing
> this particular case, how about create any parent directory
> of HOME? like:
>
> [...]
> ;; create the parent directory of HOME.
> (when home (mkdir-p (dirname home)))
David Craven writes:
> * gnu/build/activation.scm (activate-user): Make sure /var/lib exists.
> ---
> gnu/build/activation.scm | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/gnu/build/activation.scm b/gnu/build/activation.scm
> index 10aa58d..3abfdd6 100644
> --- a/gnu/build/activat
* gnu/build/activation.scm (activate-user): Make sure /var/lib exists.
---
gnu/build/activation.scm | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gnu/build/activation.scm b/gnu/build/activation.scm
index 10aa58d..3abfdd6 100644
--- a/gnu/build/activation.scm
+++ b/gnu/build/activation.scm
