GNU bug report logs - #36555
[PATCH 0/2] Refactor out common behavior for system reconfiguration.

Previous Next

Full log

Message #92 received at 36555 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: zerodaysfordays <at> sdf.lonestar.org (Jakob L. Kreuze)
Cc: 36555 <at> debbugs.gnu.org
Subject: Re: [bug#36555] [PATCH v4 2/3] guix system: Reimplement 'reconfigure'.
Date: Sat, 20 Jul 2019 16:40:54 +0200

Hello,

zerodaysfordays <at> sdf.lonestar.org (Jakob L. Kreuze) skribis:

> * guix/scripts/system.scm (switch-to-system)
> (upgrade-shepherd-services, install-bootloader): Delete variable.
> * guix/scripts/system.scm (local-eval): New variable.
    ^
No need to repeat the file name here.

However there are other changes no mentioned here, for example changes
to the ‘install’ procedure.  Could you add them to the log?

> +          (install-bootloader local-eval bootloader bootcfg
> +                              #:target target)
> +          (return
> +           (format #t "bootloader successfully installed on '~a'~%"
> +                   (bootloader-configuration-target bootloader))))))))

While you’re at it, could you change it to:

  (info (G_ "bootloader successfully installed on '~a'~%") …)

?

What happens when ‘install-bootloader’ fails though?  We should make
sure that the error is diagnosed, and that the output of ‘grub-install’
or similar is shown when that happens.

> +(define (local-eval exp)
> +  "Evaluate EXP, a G-Expression, in-place."

Eventually we should add it to (guix gexp).

> +  (mlet* %store-monad ((lowered (lower-gexp exp))
> +                       (_ (built-derivations (map gexp-input-thing
> +                                                  (lowered-gexp-inputs lowered)))))

Note that there are now a few places where we call ‘built-derivations’
without calling ‘show-what-to-build*’ first.  That means the UX might be
pretty bad since one has no idea what’s being built.

Furthermore, that means substitutes may not be up-to-date, leading to
many “updating substitutes” messages and HTTP round trips (as happened
with <https://issues.guix.gnu.org/issue/36509>).

Last, doing several ‘build-derivations’ call with just a couple of
derivations is less efficient than doing a single call with many
derivations; that also has an impact on the UI, if we were to call
‘show-what-to-build*’ once for ‘build-derivations’ call.

What’s your experience with this in practice?

There are several things we can do to improve on that.  One is to have
‘built-derivations’ automatically call ‘show-what-to-build*’.  However,
(guix derivations) must not depend on (guix ui) so we could add a
parameter to ‘run-with-store’ that would specify what to do upon
‘build-derivations’.

Last but not least, make sure to test this on your machine.  :-)

It’s sensitive code that we’d rather not break.

Thanks!

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.