bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#65788: poor information when updating using “guix time-machine”


From: Ludovic Courtès
Subject: bug#65788: poor information when updating using “guix time-machine”
Date: Sat, 28 Oct 2023 16:16:56 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Hi,

(Cc: Maxim.)

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

> $ guix time-machine -q --commit=6113e05 -- describe
> receiving objects   2% ▕█▋
>     …some time flies…
> indexing objects  21% ▕███████████████████████                                
>
>     …some time flies…
> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
>    …instant…
> Computing Guix derivation for 'x86_64-linux'... \

To be clear, the problem you see is that “Updating channel” is printed
too late, after “receiving objects” etc., right?

> Why not move this ’validate-guix-channel’ to internals.  Somehow, it is
> in guix/scripts/ because it captures ’ref’.  However, this capture is
> redundant and is normally managed by ’channel-list’.  Therefore, I would
> be tempted to have this validation for the reachable commit close to the
> “Updating” message.

Yes, that’s a good idea.

As I started looking into it, I realized we could reuse the existing
#:validate-pull mechanism of ‘latest-channel-instances’ for the purposes
of this commit check in ‘time-machine’.

The main advantage is that this would address a performance issue with
the implementation of ‘validate-guix-channel’ in commit
79ec651a286c71a3d4c72be33a1f80e76a560031, namely the fact that it opens
and traverses the repository one extra time for this check.  (The
#:validate-pull mechanism is integrated with ‘latest-channel-instances’
precisely to avoid this cost.)

Here’s my proposal to do that:

  https://issues.guix.gnu.org/66793

Ludo’.

PS: We should define rules for “Reviewed-by” tags because I don’t think
    I LGTM’d commit 79ec651a286c71a3d4c72be33a1f80e76a560031 (?).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]