[bug#36555] [PATCH v4 3/3] tests: Add reconfigure system test.

[Ludovic Courtès]

Hello,

address@hidden (Jakob L. Kreuze) skribis:

> Ludovic Courtès <address@hidden> writes:

[...]

>> I like to avoid exposing constructors so that one cannot “forge”
>> invalid objects, but let’s see…
>
> Should I use @@ for this, perhaps?

No, it’s not any better ;-), but anyway, let’s address this later.

>> (Once we’ve done that (guix graph) demonadification we discussed
>> before, perhaps we can perform run ‘shepherd-service-upgrade’ entirely
>> on the “other side”, and at that point we won’t need to expose the
>> ‘live-service’ constructor.)
>
> The main issue with calling 'shepherd-service-upgrade' on the other side
> is that we'd need to send over the service objects (the current
> 'upgrade-services-program' deals with provision symbols rather than the
> service objects themselves).
>
> I'm certain it's possible, it's just easier said than done. I've got
> time to think it through, though :)

Oh, you may be right.  :-)

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

I think you didn’t answer this specific question; thoughts?

>> 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?
>
> I haven't had too many issues with it since the G-Expressions tended to
> have few inputs, but those are some valid concerns. Would it be better
> to create derivations for locally-evaluated G-Expressions? For example,
> with 'program-file' or 'gexp->script'? I thought that evaluating them
> in-place might be better since that's one fewer store item that needs to
> be built, but if we were to turn the G-Expression into a derivation, we
> could add it to the call to 'show-what-to-build*' in 'guix system
> reconfigure'.

The number of ‘build-derivations’ calls is the same whether it’s local
or distant.

What would make a difference is having a single script instead of
three—i.e., one program that does:

  #~(begin
      (activate-system …)
      (upgrade-services …)
      (switch-system …))

I think this program could even be added to the ‘system’
derivation—i.e., as a file next to those in /run/current-system.

That way, switching to a system generation would be a matter of running
it’s ‘switch’ program.

Perhaps this should be our horizon.  WDYT?

Thanks for your feedback!

Ludo’.