From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: quirky behaviour of =?utf-8?Q?=E2=80=9Cguix_environment=E2=80=9D?= Date: Thu, 22 Feb 2018 14:17:53 +0100 Message-ID: <874lm9qi2m.fsf@mdc-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34031) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eoqlO-0003uU-FQ for guix-devel@gnu.org; Thu, 22 Feb 2018 08:18:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eoqlL-0000Ug-AJ for guix-devel@gnu.org; Thu, 22 Feb 2018 08:18:18 -0500 Received: from sinope02.bbbm.mdc-berlin.de ([141.80.25.24]:56132) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eoqlK-0000NT-VO for guix-devel@gnu.org; Thu, 22 Feb 2018 08:18:15 -0500 Received: from localhost (localhost [127.0.0.1]) by sinope02.bbbm.mdc-berlin.de (Postfix) with ESMTP id 841FA1010FA8 for ; Thu, 22 Feb 2018 14:18:10 +0100 (CET) Received: from sinope02.bbbm.mdc-berlin.de ([127.0.0.1]) by localhost (sinope02.bbbm.mdc-berlin.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfiFGyLyd7-q for ; Thu, 22 Feb 2018 14:18:05 +0100 (CET) Received: from HTCAONE.mdc-berlin.net (puck.citx.mdc-berlin.de [141.80.36.101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sinope02.bbbm.mdc-berlin.de (Postfix) with ESMTPS for ; Thu, 22 Feb 2018 14:18:05 +0100 (CET) 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" To: guix-devel@gnu.org 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 =E2=80=9Cguix environment -l=E2= =80=9D. In this particular instance a user informed me that running a =E2=80=9Cconfigure=E2=80=9D script inside of an environment spawned by =E2= =80=9Cguix environment -l guix.scm=E2=80=9D something wasn=E2=80=99t quite right. The script wo= uld check for R packages and print something like this: checking for R package scater=E2=80=A6 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 =E2=80=9Cldd=E2=80=9D from the glibc package. And sure enough,= running =E2=80=9Cldd=E2=80=9D printed =E2=80=9CFATAL: kernel too old=E2=80=9D. 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 =E2=80=9C--ad-hoc=E2=80=9D is NOT provided) =E2=80=9Cguix = environment=E2=80=9D uses =E2=80=9Cpackage-environment-inputs=E2=80=9D, which runs =E2=80=9Cpac= kage->bag=E2=80=9D and then =E2=80=9Cbag-transitive-inputs=E2=80=9D. The resulting list of packa= ges 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 =E2=80=9Cg= uix environment foo=E2=80=9D would behave just like =E2=80=9Cguix environ= ment --ad-hoc input-a-of-foo input-b-of-foo input-c-of-foo=E2=80=9D. 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 =E2=80=9CFATAL: kern= el too old=E2=80=9D. I have been trying to reproduce this with a grafted package that is already in the repository, but I failed. I tried with =E2=80=9Craptor2=E2= =80=9D, which has =E2=80=9Ccurl=E2=80=9D among its direct inputs. =E2=80=9Ccurl=E2=80=9D= 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 =E2=80=9Ccurl=E2=80=9D is a direct inputs whereas =E2=80=9Cglibc=E2=80= =9D is a build system input. Any ideas? -- Ricardo