GNU bug report logs - #33285
Installing, then removing, a package yields a different profile

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: Chris Marusich <cmmarusich <at> gmail.com>, 33285 <at> debbugs.gnu.org
Subject: bug#33285: Installing, then removing, a package yields a different profile
Date: Mon, 04 Feb 2019 19:02:16 +0100

Hello!

Ricardo Wurmus <rekado <at> elephly.net> skribis:

> Note that they differ in the inclusion of /gnu/store/h0905d946s3xarcfakan8jnblcdqxs3a-hello-2.10.drv as
> a derivation input.
>
> I guess that the problem might be in “profile-derivation”, which defines
> “inputs” like this:
>
>     (define inputs
>       (append (filter-map (lambda (drv)
>                             (and (derivation? drv)
>                                  (gexp-input drv)))
>                           extras)
>               (manifest-inputs manifest)))
>
> I pk’d at the value returned by manifest-inputs and found this:
>
> $ guix package -p .guix-profile -i hello
> The following package will be installed:
>    hello	2.10	/gnu/store/md2plii4g5sk66wg9cgwc964l3xwhrm9-hello-2.10
>
>
> ;;; ((#<gexp-input #<package hello <at> 2.10 gnu/packages/base.scm:68 31e4d80>:out>))
> 1 package in profile
> The following environment variable definitions may be needed:
>    export PATH=".guix-profile/bin${PATH:+:}$PATH"
>
> $ guix package -p .guix-profile -i coreutils
> The following package will be installed:
>    coreutils	8.30	/gnu/store/xzgfh8kdxilyymi1a8i97b1nci1iybhi-coreutils-8.30
>
>
> ;;; ((#<gexp-input #<package coreutils <at> 8.30 gnu/packages/base.scm:338 39a7000>:out> #<gexp-input "/gnu/store/md2plii4g5sk66wg9cgwc964l3xwhrm9-hello-2.10":out>))

Good catch!

> Should manifest-inputs distinguish between a package entry and a file
> entry and paper over the differences?

Actually, to do things correctly, we should really store the .drv in the
‘manifest’ file.  That way, manifest entries would always contains a
valid “lowerable” object (a package or a derivation record), as opposed
to a store reference that happens to be valid.

I’ll see if I can come up with a patch for this.

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.