GNU bug report logs - #33647
First `guix pull' behaves unexpectedly

Previous Next

Package: guix;

Reported by: Diego Nicola Barbato <dnbarbato <at> posteo.de>

Date: Thu, 6 Dec 2018 14:58:02 UTC

Severity: normal

Done: Björn Höfling <bjoern.hoefling <at> bjoernhoefling.de>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Diego Nicola Barbato <dnbarbato <at> posteo.de>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 33647 <at> debbugs.gnu.org
Subject: bug#33647: First `guix pull' behaves unexpectedly
Date: Fri, 07 Dec 2018 14:30:09 +0100
Hi,

Diego Nicola Barbato <dnbarbato <at> posteo.de> skribis:

> Ludovic Courtès <ludo <at> gnu.org> writes:

[...]

>> In addition, be aware that Bash maintains a cache of commands it looked
>> up in $PATH.  Thus it may be that, say, it had cached that ‘guix’ is
>> really /run/current-system/profile/bin/guix.  When you pulled, it didn’t
>> invalidate its cache thus you kept using that old version.
>>
>> The solution is to run “hash guix” at the Bash prompt to force cache
>> invalidation (info "(bash) Bourne Shell Builtins").
>
> I believe this is it.  This also explains why ‘which guix’ returned the
> updated guix while ‘guix --version’ claimed it was still the older
> version, which I found rather confusing.
> I am afraid being unaware of this has led me to inadvertently downgrade
> GuixSD whenever I reconfigured for the first time after a fresh install.

Yeah.  This is not strictly speaking a Guix bug, but clearly it’s a
common pitfall.  Perhaps we should print a hint upon completion?

Ludo’.




This bug report was last modified 6 years and 179 days ago.

Previous Next


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