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: swedebugia <swedebugia <at> riseup.net>
To: 33647 <at> debbugs.gnu.org
Subject: bug#33647: First `guix pull' behaves unexpectedly
Date: Wed, 19 Dec 2018 18:37:24 +0100
On 2018-12-19 13:49, Diego Nicola Barbato wrote:
> 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.

I wholeheartedly agree with Diego.

Either we fix it (preferably, even if we have to patch bash in order to 
archive what we want) or we tell the users what to do (this is bad 
because we already tell the users a lot of env variables and this just 
adds clutter and one more cumbersome thing to remember).

FWW I just ran "hash pacman" on parabola and the result was this:
egil <at> parabola:~$ time hash pacman

real	0m0,000s
user	0m0,000s
sys	0m0,000s

So it won't and any measuable overhead to just call this in the end of 
guix package after updating the symlinks to the new profile generation.

-- 
Cheers Swedebugia




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

Previous Next


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