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

[Maxim Cournoyer]

Hi Simon, Ludovic,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi Maxim,
>
> Let start another branch in that thread of #65352. :-)

Alright :-).

> Let start the discussion on good basis, let start with an example:
>
> $ 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
>
>
> So far, so good.  Here all is cached and so on.  Now, let make
> git.savannah.gnu.org unreachable by tweaking some stuff.  Then,
>
> $ 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
>
>
> Do we agree it is bug?  Do we agree that the behaviour is not POLA?

Thanks for the example, it helps :-).  I agree it's an undesirable
behavior to reach to the network after having (supposedly) cached the
very same ref.

[...]

> 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. :-)

Also, from the current state of things (the code) :-).  But I agree that
there seems to be space for improvements here.

> 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.

More annoying but also, much more likely!

> 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.

Sounds reasonable; it'll reduce some load from Savannah ;-).

>
> 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?

So all the refs such as commit(ish) or tags would be referenced locally,
and branches such as 'master' would still trigger an update.

LGTM, but I'd be curious to hear what Ludovic thinks, since their
original code treated tags as mutable (which they technically are, but I
agree to the value of treating them as immutable, and it appears low
risk to me).

-- 
Thanks,
Maxim