On 2018-12-19 13:49, Diego Nicola Barbato wrote:
Hello,
Ludovic Courtès <l...@gnu.org> writes:
Diego Nicola Barbato <dnbarb...@posteo.de> skribis:
Ludovic Courtès <l...@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@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
