From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: rootless Guix Date: Mon, 15 Oct 2018 12:02:26 +0200 Message-ID: <87zhvfh6j1.fsf@gnu.org> References: <87y3b9qzrj.fsf@mdc-berlin.de> <87va6cy2o1.fsf@gnu.org> <8736t9o70e.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37784) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gBzhp-0003Vb-MJ for guix-devel@gnu.org; Mon, 15 Oct 2018 06:02:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gBzhn-0005VI-Gf for guix-devel@gnu.org; Mon, 15 Oct 2018 06:02:33 -0400 In-Reply-To: <8736t9o70e.fsf@elephly.net> (Ricardo Wurmus's message of "Sat, 13 Oct 2018 23:45:37 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: guix-devel@gnu.org Hi Ricardo! Ricardo Wurmus skribis: > Ludovic Court=C3=A8s writes: [...] >> Right, I=E2=80=99m 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 =E2=80=98guix pa= ckage=E2=80=99 >> to make everything relocatable before adding it to the profile (like >> what =E2=80=98guix pack -R=E2=80=99 does.) > > Installing a relocatable wrapper would be fine, too, but I think it=E2=80= =99s a > little ugly that a profile generated with relocation enabled would > contain different binaries than one where this hasn=E2=80=99t been done. = I > have a slight preference for keeping the software unchanged. I agree about the ugliness. > FWIW running programs in a =E2=80=9Ccontainer environment=E2=80=9D is wha= t Docker users > are already used to. It would be fine to have =E2=80=9Cguix container --= run =E2=80=A6=E2=80=9D > or a variant of the proposed =E2=80=9Cguix run=E2=80=9D for the kinds of = people who are > used to Singularity or Docker. Right, so we could have something like =E2=80=9Cguix enter=E2=80=9D or even= simply ./bin/sh (a wrapped shell that binds /gnu/store in its namespace.) >> As for spawning guix-daemon automatically, I=E2=80=99m not sure. I=E2= =80=99d rather >> have the =E2=80=98guile-daemon=E2=80=99 branch ready and merged, and the= n use that as a >> library, rather than having to spawn a full guix-daemon process behind >> the scenes. Though of course, that=E2=80=99s a longer-term effort. > > Yes, I=E2=80=99m not really interested in running the daemon; it would be= even > better if we could avoid it of course. But I don=E2=80=99t think that th= is 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 =E2=80=99guix=E2=80=99 command line flag or an environm= ent variable) > is a solution that requires the least effort. I see. (Though in terms of effort, having just the bits of the =E2=80=98guile-daemon=E2=80=99 branch needed for this setup may not be = that much work compared to setting up the machinery to spawn =E2=80=98guix-daemon=E2= =80=99.) > 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=3Dinternal 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 =E2=80=94 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. > > =E2=80=9Cguix pack=E2=80=9D 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=E2=80=99s see how we can get there! Thanks, Ludo=E2=80=99.