Alexander Vorobiev <[email protected]> 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’.
