Re: Daemon update

[Ludovic Courtès]

Alexander Vorobiev <address@hidden> 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
     ‘guix-daemon’ binary of the tarball.

  2. The store directory that ‘guix-daemon’ targets.

#2 can actually be changed at run-time via the (purposefully
undocumented) ‘NIX_STORE_DIR’ environment variable (see ‘test-env.in’ in
the source tree.)

#1 means that if you want to run the ‘guix-daemon’ binary from the
binary tarball, you’ll have to somehow satisfy its requirements.  You
might be able to unpack the tarball in an arbitrary directory, and then
define ‘LD_LIBRARY_PATH’ so that ‘guix-daemon’ 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 ‘guix-daemon’ is running, you could run ‘guix environment guix’,
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 ‘make guix-binary.x86_64-linux.tar.xz’.

WDYT?

Ludo’.