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, 08 Oct 2018 15:43:26 +0200 Message-ID: <87va6cy2o1.fsf@gnu.org> References: <87y3b9qzrj.fsf@mdc-berlin.de> 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]:40289) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g9Vp3-0007Ia-1w for guix-devel@gnu.org; Mon, 08 Oct 2018 09:43:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g9Vov-0003n0-T6 for guix-devel@gnu.org; Mon, 08 Oct 2018 09:43:44 -0400 In-Reply-To: <87y3b9qzrj.fsf@mdc-berlin.de> (Ricardo Wurmus's message of "Sun, 7 Oct 2018 22:15:44 +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 Hello! Ricardo Wurmus skribis: > it would be nice if we could simplify the case where a user does not > have root access, but the system supports user namespaces. > > Currently, a user would have to perform a number of non-obvious steps to > somehow run the Guix daemon in an environment where the filesystem is > virtualized. It would be great if we could better support this case, > maybe even simplify it to a point where the user does not have to even > start the daemon by themselves. For the record, here=E2=80=99s what needs to be done to run guix-daemon and= guix as produced by =E2=80=98guix pack --relocatable guix=E2=80=99: https://lists.gnu.org/archive/html/guix-devel/2018-05/msg00139.html We could certainly arrange so that users don=E2=80=99t have to fiddle with $NIX_STATE_DIR etc. > A user operating in this mode would lose the ability to share with other > users on the same system, of course. By default Guix could store > everything in a subdirectory of ~/.local and map that to /gnu/store in > the container context. Applications would also need to be run from > within that container context to ensure that /gnu/store file names are > resolved properly. 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 packa= ge=E2=80=99 to make everything relocatable before adding it to the profile (like what =E2=80=98guix pack -R=E2=80=99 does.) 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 then u= se 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. > I think this would be especially useful for situations where =E2=80=9Cgui= x pack=E2=80=9D > is not sufficient. =E2=80=9Cguix pack=E2=80=9D produces one-shot bundles= , but it cannot > be composed. A daemon+store-in-container setup would be extensible. > > What do you think about this? Can we automate the setup necessary for > this scenario and add better defaults? I think it takes some reasonable effort, it would be nice, but I=E2=80=99m = not entirely sure if it=E2=80=99s worth the effort (maybe it is, I really don= =E2=80=99t know.) WDYT? Thanks, Ludo=E2=80=99.