quirky behaviour of “guix environment”

[Ricardo Wurmus]

Hi Guix,

for a few days now I have been testing the glibc graft to make software
work on the cluster running CentOS 6.8 (with a heavily patched Linux
that has the nominal version 2.6.32).

The graft seems to work fine (with the exception of a Guile GC warning I
get when running Guix), except when using “guix environment -l”.

In this particular instance a user informed me that running a
“configure” script inside of an environment spawned by “guix environment
-l guix.scm” something wasn’t quite right.  The script would check for R
packages and print something like this:

    checking for R package scater… FATAL: kernel too old
    yes

The check succeeded but somewhere a program was spawned that used the
ungrafted glibc!  I entered the environment myself and noticed that it
contained “ldd” from the glibc package.  And sure enough, running “ldd”
printed “FATAL: kernel too old”.

There are two things I find odd:

1.) the environment includes glibc and its executables.  Is this ever
    desired?  When loading an environment from a file or from a package
    (i.e. when “--ad-hoc” is NOT provided) “guix environment” uses
    “package-environment-inputs”, which runs “package->bag” and then
    “bag-transitive-inputs”.  The resulting list of packages is then
    used as the inputs for a profile derivation.  That seems a bit
    excessive.

    Would it not be sufficient to use only the direct inputs of the
    package as the inputs to the profile derivation?  That way “guix
    environment foo” would behave just like “guix environment --ad-hoc
    input-a-of-foo input-b-of-foo input-c-of-foo”.

    Is there a reason why it creates a whole bag and dumps its contents
    into the inputs of the profile derivation?

2.) How could the *old* glibc end up in the environment?  I expected the
    grafted glibc, which comes with a patch to avoid “FATAL: kernel too
    old”.

I have been trying to reproduce this with a grafted package that is
already in the repository, but I failed.  I tried with “raptor2”, which
has “curl” among its direct inputs.  “curl” has a replacement.  The
replacement ended up in the environment as expected.

I wonder if the difference in behaviour can be explained by the fact
that “curl” is a direct inputs whereas “glibc” is a build system input.

Any ideas?

--
Ricardo