[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: thesis: guixsd should provide /usr/bin/env
From: |
Andy Wingo |
Subject: |
Re: thesis: guixsd should provide /usr/bin/env |
Date: |
Thu, 19 Nov 2015 17:35:32 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
On Thu 19 Nov 2015 16:07, address@hidden (Ludovic Courtès) writes:
> My current inclination would be to not provide /usr/bin/env by default,
> and instead let users add it if they want to, either using the
> sledgehammer Ricardo suggests ;-), or simply with:
>
> ln -s /run/current-system/profile/bin/env /usr/bin/env
>
> We could document it, and/or even add a switch in ‘operating-system’ to
> do that.
>
> How does that sound?
Fine with me. My use case is when working on Chromium, which has a
bunch of scripts that are part of its development environment. Most of
them start with /usr/bin/env, just a couple don't and I think those are
bugs. In practice though that's something of a hack and what I really
should go for is the --container thing...
>> Alternately, I am not sure if this would work but we could make a form
>> of "guix environment" which populates a profile that is mounted at /usr
>> in a container. That would allow many more non-Guix tools to run.
>
> Technically ‘guix environment --container’ could create /usr, just like
> it creates /bin/sh. Not sure if it’s a good idea, though.
I think it is definitely interesting. The reason being, you might hack
on something or have to deploy something and it's not part of Guix --
you don't want to rewrite the shebang lines for files in git that aren't
build products. Being able to make a just-FHS-enough environment inside
a container sounds to me like a useful tool to have for shimming Guix
and the outside world, while also benefitting from Guix's reproducible
environments, rollbacks, isolation, and so on.
Andy