guix-patches
[Top][All Lists]
Advanced

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

[bug#36555] [PATCH v4 2/3] guix system: Reimplement 'reconfigure'.


From: Ludovic Courtès
Subject: [bug#36555] [PATCH v4 2/3] guix system: Reimplement 'reconfigure'.
Date: Sat, 20 Jul 2019 16:40:54 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

Hello,

address@hidden (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’.





reply via email to

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