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

Previous Next

Full log

Message #28 received at 33647 <at> debbugs.gnu.org (full text, mbox):

From: Diego Nicola Barbato <dnbarbato <at> posteo.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 33647 <at> debbugs.gnu.org
Subject: Re: bug#33647: First `guix pull' behaves unexpectedly
Date: Wed, 19 Dec 2018 13:49:17 +0100

Hello,

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

> 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?

While I think it would be nice for Guix (or strictly speaking Bash) to
just do what a noob like me would expect it to do in this situation, a
hint would have certainly saved me some trouble.  If it is unreasonably
cumbersome to make Guix tell Bash to invalidate its cache upon
completion of ‘guix pull’, I believe a hint would be good enough.

Greetings,

Diego

Previous Next

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