unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: taylanbayirli@gmail.com (Taylan Ulrich Bayırlı/Kammer)
To: Alexander Vorobiev <alexander.vorobiev@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: Daemon update
Date: Fri, 22 May 2015 10:35:12 +0200	[thread overview]
Message-ID: <87k2w1vwlb.fsf@T420.taylan> (raw)
In-Reply-To: <CAGOCFPUhZVpB6ZKR4gEejzHeePV5bSWAZONqpam65aeSOD=M0Q@mail.gmail.com> (Alexander Vorobiev's message of "Thu, 21 May 2015 20:47:48 -0500")

Alexander Vorobiev <alexander.vorobiev@gmail.com> 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	other threads:[~2015-05-22  8:35 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-19 14:15 Daemon update Ludovic Courtès
2015-05-21  3:03 ` Alex Vorobiev
2015-05-21  7:24   ` Taylan Ulrich Bayırlı/Kammer
2015-05-21  8:24   ` Ludovic Courtès
2015-05-22  1:47     ` Alexander Vorobiev
2015-05-22  8:35       ` Taylan Ulrich Bayırlı/Kammer [this message]
2015-05-22 13:45       ` Ludovic Courtès
2015-05-27  3:27         ` Alexander Vorobiev
2015-05-27 15:18           ` Ludovic Courtès
2015-05-27 20:10             ` Alexander Vorobiev
2015-05-27 20:51               ` Ludovic Courtès
2015-05-28 17:56                 ` Alexander Vorobiev
2015-05-29 20:57                   ` Ludovic Courtès
2015-05-29 22:34                     ` Alexander Vorobiev
2015-05-31 19:14                       ` Ludovic Courtès
2015-06-01 16:50                         ` Alexander Vorobiev
2015-06-01 19:58                           ` Ludovic Courtès
2015-06-01 20:23                             ` Alexander Vorobiev
2015-06-02  5:26                               ` Alexander Vorobiev
2015-06-03  8:24                                 ` Ludovic Courtès
2015-06-03 16:04                                   ` Alexander Vorobiev
  -- strict thread matches above, loose matches on Subject: below --
2015-05-12  7:58 Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k2w1vwlb.fsf@T420.taylan \
    --to=taylanbayirli@gmail.com \
    --cc=alexander.vorobiev@gmail.com \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).