Re: A package picks up a non-master package - bug or intentional?

[Ricardo Wurmus <rekado@elephly.net>]

ng0 <contact.ng0@cryptolab.net> writes:

> I just picked up gnunet-fuse again and the build behaves strange.
>
> You have to know that I keep multiple versions of gnunet and related
> packages in my GUIX_PACKAGE_PATH.
> Normally I would expect that this:
>
> +    (arguments
> +     `(#:configure-flags
> +       (list (string-append "--with-gnunet="
> +                            (assoc-ref %build-inputs "gnunet")))))
>
> just picks up the gnunet from within the master tree the package
> definition itself is in.
> But as I recently have build "gnunetgf-0.10.17731daf5" this is being
> picked up instead as you can see here:
>
> checking fuse.h usability... yes
> checking fuse.h presence... yes
> checking for fuse.h... yes
> checking for GNUnet core... /gnu/store/xbvcn8fqp5l45dh5s32nmqmvbykahq7k-gnunetgf-0.10.17731daf5
> checking for GNUnet util library in /gnu/store/xbvcn8fqp5l45dh5s32nmqmvbykahq7k-gnunetgf-0.10.17731daf5... checking for gnunet/gnunet_util_lib.h... no
> configure: error: gnunet-fuse requires GNUnet
> phase `configure' failed after 2.8 seconds
>
>
> I wonder.. why? Is Guix just not clever enough and picks the first
> fitting "gnunet" it finds and if already available its store path?

Guix doesn’t *look* for any packages, so it doesn’t need to be clever.
You *tell* it what exact package to use.  Only packages that you have
declared as inputs will be available.  To declare a package as an input
you add *the package itself* (by unquoting a symbol that evaluates to a
package value).  There is no ambiguity, neither at build time nor at
runtime of Guix.

The confusion here is probably in what package value the symbol in the
inputs resolves to.  And this depends on the modules that are loaded.
We would need to see the full package definition and see what values the
package variables correspond to.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net