guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Daemon update


From: Taylan Ulrich Bayırlı/Kammer
Subject: Re: Daemon update
Date: Fri, 22 May 2015 10:35:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Alexander Vorobiev <address@hidden> writes:

> Doesn't binary distribution have hardcoded /gnu/* paths? 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. 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?

I'm afraid it's not the daemon itself for which changing the store path
is problematic (although it's not supported at run-time AFAIK, only at
configure-time via --with-store-dir=), it's that any built packages in
/gnu/store are likely to have "hardcoded" absolute references to other
/gnu/store files.

I think this can't really be avoided either, because some pieces of
software have configuration files and such which only support plain file
paths without any dynamic parameterization, meaning the recipe for the
package has to patch said files to contain absolute references to
/gnu/store files when they have to refer to any files from their
dependencies.

For example, when sources of package A contain a dlopen() call to open a
library from package B, then A's source is patched to turn the file name
argument to dlopen() into an absolute path to package B's library file
in /gnu/store.  That is because dlopen() does not support changes to its
search path in a portable manner.  (Maybe one day we will hack dlopen to
fix this, but it's just one example.)

This would mean that to use a non-standard store directory, you will
have to build Guix packages locally, as well as Guix itself.  Unless I'm
missing something.


You could still use the binary tarballs to install Guix on a machine
where you are permitted to, so you can easily compile another Guix via
the method described at the bottom here:

https://lists.gnu.org/archive/html/guix-devel/2015-05/msg00360.html


I'm afraid this doesn't help very much, but it's all I've got. :-\

Taylan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]