[bug#65352] time-machine, unavailable network or Savannah down

[Simon Tournier]

Hi Maxim,

Let start another branch in that thread of #65352. :-)

Let start the discussion on good basis, let start with an example:

--8<---------------cut here---------------start------------->8---
$ guix describe
Generation 26   Jul 12 2023 09:13:39    (current)
  guix 4a027d2
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 4a027d2b0ee68e39f21f6802a8cd1751d3065330

$ guix time-machine --commit=4a027d2 -- describe
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
building 
/gnu/store/sg8ca36rlbh4il6jy8dk2gr33lxm4z8q-compute-guix-derivation.drv...
Computing Guix derivation for 'x86_64-linux'... |
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
The following derivations will be built:
[...]
building profile with 1 package...
  guix 4a027d2
    repository URL: https://git.savannah.gnu.org/git/guix.git
    commit: 4a027d2b0ee68e39f21f6802a8cd1751d3065330
--8<---------------cut here---------------end--------------->8---

So far, so good.  Here all is cached and so on.  Now, let make
git.savannah.gnu.org unreachable by tweaking some stuff.  Then,

--8<---------------cut here---------------start------------->8---
$ guix time-machine --commit=4a027d2 -- describe
guix time-machine: error: Git error: failed to resolve address for 
git.savannah.gnu.org: Name or service not known
--8<---------------cut here---------------end--------------->8---

Do we agree it is bug?  Do we agree that the behaviour is not POLA?

It is the same when specifying a release tag,

--8<---------------cut here---------------start------------->8---
$ guix time-machine --commit=v1.4.0 -- describe
guix time-machine: error: Git error: failed to resolve address for 
git.savannah.gnu.org: Name or service not known
--8<---------------cut here---------------end--------------->8---

I think Guix needs to be reliable whatever the status of Savannah when a
local Git ref is in the local cached checkout.


After this introduction, let start the core discussion.


On Tue, 05 Sep 2023 at 22:00, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

> I don't know if we want to consider tags are immutable or not; the
> safest is to consider them an *not* immutable, which is what we had been
> doing.  I agree it doesn't cover all the potential git refspecs; we can
> get there if we want (although I suppose it's uncommon for someone to
> try 'guix time-machine --commit=v1.3.0-47405-ge0767a24d0' or similar).

[...]

> I'm not sure if short commit IDs should be treated as immutable, since
> in theory they can collide; the safest would be to check if there are
> collisions and report an error if there is; and this requires fetching
> new objects first.

Well, the behaviour that I want is that it just works whatever the
status of Savannah when I have a local Git ref that matches what I
provide to ’guix time-machine’ (or guix pull or else).

I think you are inferring a rule from two corner-cases.  And from my
point of view, there are only hypothetical. :-)

1. About tag.  The ones from upstream are defacto immutable.  It is
uncommon that people set local tag under ~/.cache/guix/checkouts.  And,
the failure when Savannah is unreachable appears to me more annoying
than hypothetical mutable tags.  Therefore, I propose what I already
proposed. :-) It will make it works for most of the cases.

Even, what would happen if a tag is changed?  The user does not get the
same inferior for two invocations.  The question is: what triggers the
update of the cached checkout?

What is the consequence for not updating when the user-specified Git ref
is a mutable one (tag or else)?  Here, I am proposing to delay the
update until the next “guix pull” or “guix time-machine -q”, well until
the user invokes a command with a Git ref that does not belong to the
local cached checkout.

I do not see why this delay is a problem.  And it avoids an update.


2. About short commit IDs.  The same reasoning applies. :-)

About the collision, it is the same.  It only delays the collision
report.


All in all, I think that reference-available? needs to check if the Git
ref belongs to the local cached checkout and that’s all.  If it is, use
it, else update the local cached checkout.

At time t, the user-specificity Git ref can match some local Git ref but
not the upstream state.  And so?

Somehow, I am considering the local cached checkout as the primary
reference for looking up Git ref.

Do you see a potential issue that I am missing?


Cheers,
simon