Re: rootless Guix

[Ludovic Courtès]

Hi Ricardo!

Ricardo Wurmus <address@hidden> skribis:

> Ludovic Courtès <address@hidden> writes:

[...]

>> Right, I’m not sure what to do with binaries installed with this
>> relocatable Guix: either we let the user run them from a relocatable
>> shell that maps /gnu/store appropriately (as in the message above),
>> which works but is inconvenient, or we somehow instruct ‘guix package’
>> to make everything relocatable before adding it to the profile (like
>> what ‘guix pack -R’ does.)
>
> Installing a relocatable wrapper would be fine, too, but I think it’s a
> little ugly that a profile generated with relocation enabled would
> contain different binaries than one where this hasn’t been done.  I
> have a slight preference for keeping the software unchanged.

I agree about the ugliness.

> FWIW running programs in a “container environment” is what Docker users
> are already used to.  It would be fine to have “guix container --run …”
> or a variant of the proposed “guix run” for the kinds of people who are
> used to Singularity or Docker.

Right, so we could have something like “guix enter” or even simply
./bin/sh (a wrapped shell that binds /gnu/store in its namespace.)

>> As for spawning guix-daemon automatically, I’m not sure.  I’d rather
>> have the ‘guile-daemon’ branch ready and merged, and then use that as a
>> library, rather than having to spawn a full guix-daemon process behind
>> the scenes.  Though of course, that’s a longer-term effort.
>
> Yes, I’m not really interested in running the daemon; it would be even
> better if we could avoid it of course.  But I don’t think that this can
> be accomplished within a reasonable time frame.  We have that depedency
> on the daemon now and it seems to me that starting it automatically (in
> the presence of a ’guix’ command line flag or an environment variable)
> is a solution that requires the least effort.

I see.  (Though in terms of effort, having just the bits of
the ‘guile-daemon’ branch needed for this setup may not be that much
work compared to setting up the machinery to spawn ‘guix-daemon’.)

> My goal really is to free the user from thinking about the daemon at
> all.  When the user has indicated (how?) that it is preferable to keep
> the store somewhere in ~/.local and use file system virtualization, then
> we could take care of the daemon and everything that belongs to it.

One way to configure it might be to set GUIX_DAEMON_SOCKET=internal or
something along these lines.

Something that works without config would be better, but it seems
difficult to achieve without breaking current multi-user setups.

> If it allows users on single-user systems to use Guix easily without
> having to be root then I think it would very well be worth the effort.
> The dependency on a daemon that runs as root is still often considered
> an obstacle — you probably also know that Singularity got a big
> popularity boost purely for circumventing the need for a root daemon (by
> using a setuid binary, which admins seem not to worry or know about).
> Allowing people in certain situations to forget about the daemon might
> have a similarly positive effect on how people perceive the setup
> complexity of Guix.
>
> “guix pack” is great for using software on systems where Guix cannot be
> used, but its output for one package closure cannot be composed with the
> output of another package closure.  By making the daemon run in a
> container we can bring more of the features of Guix to these limited
> systems.

OK, that makes sense.  Well, let’s see how we can get there!

Thanks,
Ludo’.