Hello,

I think I've confused things a bit. Well, 'guix refresh' updates package
definitions to match the latest upstream version, but we are the
upstream, so it is not useful here.

I think even if 'guix pull' is being run, the guix installed should
always be newer than the guix known to guix, right?

It is due to how release is done and how 'guix pull' works.

When releasing, a commit X is declared as a release. The release tarball
then contains commit X. The next commit Y changes the snapshot of the
guix known to guix from some old value to X. But the release tarball
still contains the old value since it uses commit X! So if you installed
from a release tarball and have not run 'guix pull' yet, the guix
installed should be newer than the guix known to guix.

Similarly, when running 'guix pull', say master is at commit X, and the
snapshot of the guix known to guix inside that commit X is at commit
Y. Then the guix installed is updated to commit X and the guix known to
guix is updated to commit Y.

Now we observe that commit X is always newer than commit Y. It is
because when you update snapshot, you change the snapshot to the current
commit and then commit. After that, the commit of the snapshot is
already 1 commit behind that of the new current commit! So after you run
'guix pull', the guix installed should be newer than the guix known to
guix.

As a result, the guix installed should always be newer than the guix
known to guix. Is my reasoning valid?

ludo@gnu.org (Ludovic Courtès) writes:

> Hi,
>
> Alex Vong <alexvong1995@gmail.com> skribis:
>
>> I think if you never run 'guix refresh', then the guix installed should
>> always be newer than the guix known to guix.
>
> I think you mean ‘guix pull’, in which case I agree.
>
> (‘guix refresh’ is more of a developer tool: it simplifies updating
> package definitions.)
>
> Ludo’.