GNU bug report logs - #54377
[PATCH 0/3] Add 'guix home container'

Previous Next

Full log

View this message in rfc822 format

From: Andrew Tropin <andrew <at> trop.in>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 54377 <at> debbugs.gnu.org
Subject: [bug#54377] [PATCH 0/3] Add 'guix home container'
Date: Sat, 19 Mar 2022 18:03:40 +0300

[Message part 1 (text/plain, inline)]

On 2022-03-19 11:39, Ludovic Courtès wrote:

> Hi,
>
> Andrew Tropin <andrew <at> trop.in> skribis:
>
>> What I meant by previous comment: to match a real state of the things
>> it's better to use a shell from /etc/passwd, because it will be launched
>> on user login and will read env vars and run all the following
>> processes, but to make it more reproducible and independent from system
>> state I think we always have to use hardcoded bash and inside the
>> container inspect the value of $SHELL set by login shell (hardcoded
>> bash) and spawn new shell if $SHELL is NOT empty.
>
> Yeah, there’s a tension between conflicting criteria: independence from
> system state, and faithful reproduction of what would happen on the
> system.  I feel like checking $SHELL is a middle ground.
>
> I don’t know, we can revisit that as we gain more experience with the
> tool I guess.

I think the good implementation will be a hardcoded bash (or other shell
defined in /etc/passwd) launched as a login shell, which tries to
execute $SHELL if it is present in bash_profile or somewhere else in
shell startup files (not the $SHELL defined in host environment, but the
one which will be set inside container by login shell).  It both makes
the container reproducible and adds possibility to use patched zsh, fish
or whatever unusual shell user set in his $SHELL.

The current solution probably ok as well.

-- 
Best regards,
Andrew Tropin

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.