[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33647: First `guix pull' behaves unexpectedly
From: |
Ludovic Courtès |
Subject: |
bug#33647: First `guix pull' behaves unexpectedly |
Date: |
Fri, 18 Jan 2019 17:54:58 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Hi Diego,
Diego Nicola Barbato <address@hidden> skribis:
> Ludovic Courtès <address@hidden> writes:
>
>> Diego Nicola Barbato <address@hidden> skribis:
>>
>>> Ludovic Courtès <address@hidden> 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.
Thanks for the heads-up. Commit
3bbd6919bd84b76686d1aa626ba861faf3fc8ceb changes ‘guix pull’ to display
a hint in this case.
Ludo’.
- bug#33647: First `guix pull' behaves unexpectedly,
Ludovic Courtès <=