From: "Ludovic Courtès" <ludo@gnu.org>
To: "Jakob L. Kreuze" <zerodaysfordays@sdf.lonestar.org>
Cc: 36555@debbugs.gnu.org
Subject: [bug#36555] [PATCH v4 3/3] tests: Add reconfigure system test.
Date: Tue, 23 Jul 2019 23:47:05 +0200 [thread overview]
Message-ID: <87o91kzana.fsf@gnu.org> (raw)
In-Reply-To: <87zhl69box.fsf@sdf.lonestar.org> (Jakob L. Kreuze's message of "Mon, 22 Jul 2019 14:16:46 -0400")
Hello,
zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) skribis:
> Ludovic Courtès <ludo@gnu.org> 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’.
next prev parent reply other threads:[~2019-07-23 21:48 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-08 19:52 [bug#36555] [PATCH 0/2] Refactor out common behavior for system reconfiguration Jakob L. Kreuze
2019-07-08 19:59 ` [bug#36555] [PATCH 1/2] guix system: Add 'reconfigure' module Jakob L. Kreuze
2019-07-08 20:01 ` [bug#36555] [PATCH 2/2] guix system: Reimplement 'reconfigure' Jakob L. Kreuze
2019-07-13 10:23 ` [bug#36555] [PATCH 1/2] guix system: Add 'reconfigure' module Ludovic Courtès
2019-07-13 17:44 ` Jakob L. Kreuze
2019-07-14 13:23 ` Ludovic Courtès
2019-07-15 15:36 ` Jakob L. Kreuze
2019-07-15 16:32 ` Ludovic Courtès
2019-07-15 23:57 ` Jakob L. Kreuze
2019-07-16 23:46 ` [bug#36555] [PATCH v3 0/3] Refactor out common behavior for system reconfiguration Jakob L. Kreuze
2019-07-16 23:47 ` [bug#36555] [PATCH v3 1/3] guix system: Add 'reconfigure' module Jakob L. Kreuze
2019-07-16 23:48 ` [bug#36555] [PATCH v3 2/3] guix system: Reimplement 'reconfigure' Jakob L. Kreuze
2019-07-16 23:48 ` [bug#36555] [PATCH v3 3/3] tests: Add reconfigure system test Jakob L. Kreuze
2019-07-19 11:57 ` [bug#36555] [PATCH v3 1/3] guix system: Add 'reconfigure' module Ludovic Courtès
2019-07-18 22:50 ` [bug#36555] [PATCH v3 0/3] Refactor out common behavior for system reconfiguration Jakob L. Kreuze
2019-07-19 17:54 ` [bug#36555] [PATCH v4 " Jakob L. Kreuze
2019-07-19 17:55 ` [bug#36555] [PATCH v4 1/3] guix system: Add 'reconfigure' module Jakob L. Kreuze
2019-07-19 17:58 ` [bug#36555] [PATCH v4 2/3] guix system: Reimplement 'reconfigure' Jakob L. Kreuze
2019-07-19 17:59 ` [bug#36555] [PATCH v4 3/3] tests: Add reconfigure system test Jakob L. Kreuze
2019-07-20 14:50 ` Ludovic Courtès
2019-07-22 18:16 ` Jakob L. Kreuze
2019-07-22 18:23 ` Jakob L. Kreuze
2019-07-22 18:54 ` [bug#36555] [PATCH v5 0/3] Refactor out common behavior for system reconfiguration Jakob L. Kreuze
2019-07-22 18:56 ` [bug#36555] [PATCH v5 1/3] guix system: Add 'reconfigure' module Jakob L. Kreuze
2019-07-22 18:57 ` [bug#36555] [PATCH v5 2/3] guix system: Reimplement 'reconfigure' Jakob L. Kreuze
2019-07-22 18:57 ` [bug#36555] [PATCH v5 3/3] tests: Add reconfigure system test Jakob L. Kreuze
2019-07-23 22:30 ` [bug#36555] [PATCH v5 2/3] guix system: Reimplement 'reconfigure' Ludovic Courtès
2019-07-24 0:06 ` Jakob L. Kreuze
2019-07-24 0:48 ` Jakob L. Kreuze
2019-07-24 16:33 ` [bug#36555] [PATCH v6 0/3] Refactor out common behavior for system reconfiguration Jakob L. Kreuze
2019-07-24 16:34 ` [bug#36555] [PATCH v6 1/3] guix system: Add 'reconfigure' module Jakob L. Kreuze
2019-07-24 16:34 ` [bug#36555] [PATCH v6 2/3] guix system: Reimplement 'reconfigure' Jakob L. Kreuze
2019-07-24 16:35 ` [bug#36555] [PATCH v6 3/3] tests: Add reconfigure system test Jakob L. Kreuze
2019-07-26 16:59 ` bug#36555: " Ludovic Courtès
2019-07-26 17:53 ` [bug#36555] " Jakob L. Kreuze
2019-07-24 22:46 ` [bug#36555] [PATCH v5 2/3] guix system: Reimplement 'reconfigure' Ludovic Courtès
2019-07-23 21:47 ` Ludovic Courtès [this message]
2019-07-24 0:01 ` [bug#36555] [PATCH v4 3/3] tests: Add reconfigure system test Jakob L. Kreuze
2019-07-24 22:44 ` Ludovic Courtès
2019-07-20 14:40 ` [bug#36555] [PATCH v4 2/3] guix system: Reimplement 'reconfigure' Ludovic Courtès
2019-07-20 14:29 ` [bug#36555] [PATCH v4 1/3] guix system: Add 'reconfigure' module Ludovic Courtès
2019-07-30 16:55 ` Jakob L. Kreuze
2019-08-23 21:00 ` Ludovic Courtès
2019-07-19 17:56 ` Jakob L. Kreuze
2019-07-19 19:36 ` [bug#36555] [PATCH v3 0/3] Refactor out common behavior for system reconfiguration Christopher Lemmer Webber
2019-07-22 16:18 ` Jakob L. Kreuze
2019-07-22 16:39 ` Christopher Lemmer Webber
2019-07-09 13:26 ` [bug#36555] [PATCH 0/2] " Christopher Lemmer Webber
2019-07-09 19:07 ` [bug#36555] [PATCH v2 0/3] " Jakob L. Kreuze
2019-07-09 19:08 ` [bug#36555] [PATCH v2 1/3] guix system: Add 'reconfigure' module Jakob L. Kreuze
2019-07-09 19:09 ` [bug#36555] [PATCH v2 2/3] guix system: Reimplement 'reconfigure' Jakob L. Kreuze
2019-07-09 19:09 ` [bug#36555] [PATCH v2 3/3] tests: Add reconfigure system test Jakob L. Kreuze
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o91kzana.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=36555@debbugs.gnu.org \
--cc=zerodaysfordays@sdf.lonestar.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).