From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Daemon update Date: Fri, 22 May 2015 15:45:18 +0200 Message-ID: <877fs0k9ox.fsf@gnu.org> References: <87siasirgo.fsf@gnu.org> <87a8wy5oet.fsf@gnu.org> 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]:46273) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvnGP-0005wl-PU for guix-devel@gnu.org; Fri, 22 May 2015 09:45:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YvnGL-0007cK-MY for guix-devel@gnu.org; Fri, 22 May 2015 09:45:25 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50600) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvnGL-0007cG-JZ for guix-devel@gnu.org; Fri, 22 May 2015 09:45:21 -0400 In-Reply-To: (Alexander Vorobiev's message of "Thu, 21 May 2015 20:47:48 -0500") 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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Alexander Vorobiev Cc: guix-devel@gnu.org Alexander Vorobiev skribis: > Doesn't binary distribution have hardcoded /gnu/* paths? Yes it does. > I can't use those unfortunately. We have a standard configuration of > RHEL 6.5 installed on hundreds of servers and any modifications of the > root directory (and all other "standard" directories) layout are out > of question. OK. Note that using a store other than /gnu/store prevents you from using substitutes from hydra.gnu.org (just mentioning it if that is of interest to you.) > Would it be too hard to add an environment variable(s) pointing to a > Guix's store and cache directories so that the binary build of the > daemon doesn't depend on the hardcoded values? Thanks, Alex There are two issues here: 1. File names hard-coded in the RUNPATH and other places of the =E2=80=98guix-daemon=E2=80=99 binary of the tarball. 2. The store directory that =E2=80=98guix-daemon=E2=80=99 targets. #2 can actually be changed at run-time via the (purposefully undocumented) =E2=80=98NIX_STORE_DIR=E2=80=99 environment variable (see =E2= =80=98test-env.in=E2=80=99 in the source tree.) #1 means that if you want to run the =E2=80=98guix-daemon=E2=80=99 binary f= rom the binary tarball, you=E2=80=99ll have to somehow satisfy its requirements. Y= ou might be able to unpack the tarball in an arbitrary directory, and then define =E2=80=98LD_LIBRARY_PATH=E2=80=99 so that =E2=80=98guix-daemon=E2=80= =99 finds all the .so files that it needs and are provided by the binary tarball (libstdc++.so, libgcrypt.so, libsqlite3.so, libc.so, etc.) Once =E2=80=98guix-daemon=E2=80=99 is running, you could run =E2=80=98guix = environment guix=E2=80=99, and from there you could build Guix from source. But that is really hacky, and perhaps not particularly easier than building a newer GCC on your machine. Alternately, you could build a suitable binary tarball on another machine: just install and configure Guix with the options that you need, and run =E2=80=98make guix-binary.x86_64-linux.tar.xz=E2=80=99. WDYT? Ludo=E2=80=99.