Re: guix 0.7 installation

[ludo@gnu.org (Ludovic Courtès)]

Federico Beffa <beffa@ieee.org> skribis:

> Having played with guix a little bit, I have a few questions:
>
> - My locally built guix is now built with references to guix libraries
>   (in /gnu/store). What happens if I "guix pull" and "guix package -u"
>   and then garbage collect old profiles and packages?  Is it possible
>   that at some point my guix will break?

It’s possible.  However, since all the tools needed to build Guix are
now in your profile, you’ll always be able to do ‘make clean && make &&
make install’.

> - Every time I use guix I get the following note:
>
>   ;;; note: source file /usr/local/share/guile/site/2.0/srfi/srfi-37.scm
>   ;;;       newer than compiled /usr/local/share/guile/site/2.0/srfi/srfi-37.go
>
>   I guess it is just a matter of recompiling the module, but the
>   "make install" procedure should in principle get it right.

Indeed.  Having checked the makefile, I don’t see why it doesn’t happen,
since ‘make install’ does do the right thing for all the other .go
files.

However, I wouldn’t worry too much, since this file is no longer needed
if you use a recent Guile.

> - Out of curiosity I've installed the guix package into my store. The
>   installation procedure suggested to define the following environment
>   variables:
>
>   export GUILE_LOAD_PATH="$HOME/.guix-profile/share/guile/site/2.0"
>   export GUILE_LOAD_COMPILED_PATH="$HOME/.guix-profile/share/guile/site/2.0"
>
>   I did that. However, the guix package binary was still pointing to
>   my local copy of object files in "/usr/local/share/guile/...". That
>   sounded a little worrying to me. For this reason, for the moment, I
>   just removed the guix package. Is there a way to force the guix
>   package binary to only look in the store for object files?

If you look at the ‘guix’ program, you’ll see that it adds its own
module directory at the front of the search path.

Thus, /usr/local/bin/guix will always look at things in
/usr/local/share/guile first.  Conversely, /gnu/.../bin/guix will always
look at /gnu/.../share/guile first.  This is on purpose, to make sure we
don’t inadvertently mix different versions.

(Actually the very first thing in the search path is
~/.config/guix/latest, which is populated by ‘guix pull’.)

> - If I would install the guix package and uninstall the locally built
>   one from /usr/local, how would a new user be able to start using
>   guix?

They could get started by using, say, ~federico/.guix-profile/bin/guix
to install Guix in their own profile.

> - To use the build tools from the stores I've defined the following
>   environment variables:
>
>   export PKG_CONFIG_PATH="$HOME/.guix-profile/lib/pkgconfig"
>   export ACLOCAL_PATH="$HOME/.guix-profile/share/aclocal"
>   export CPATH="$HOME/.guix-profile/include"
>   export LIBRARY_PATH="$HOME/.guix-profile/lib"
>
>   Is it possible that having these variables defined does interfere
>   with the workings of my host distribution (Debian 7.6)? What
>   happens, say, if an install script for a Debian package makes use of
>   pkg-config (or any other tool) and there is a difference between the
>   one expected by the Debian package (reported by ATP tools) and the
>   one found on my system? Should I better not have these variables
>   defined by default?

I don’t think APT’s scripts can be influenced by these environment
variables, at least as long as they’re not defined in a global file such
as /etc/profile.

Most of us have been using Guix on top of some other distro anyway, at
least until recently.

Thanks,
Ludo’.