From mboxrd@z Thu Jan 1 00:00:00 1970 From: taylanbayirli@gmail.com (Taylan Ulrich =?utf-8?Q?Bay=C4=B1rl=C4=B1?= =?utf-8?Q?=2FKammer?=) Subject: Re: Daemon update Date: Fri, 22 May 2015 10:35:12 +0200 Message-ID: <87k2w1vwlb.fsf@T420.taylan> References: <87siasirgo.fsf@gnu.org> <87a8wy5oet.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51744) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YviQH-0007K9-HB for guix-devel@gnu.org; Fri, 22 May 2015 04:35:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YviQG-0002Ma-Az for guix-devel@gnu.org; Fri, 22 May 2015 04:35:17 -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 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