From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:36192) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hq2df-0002Zx-Ai for guix-patches@gnu.org; Tue, 23 Jul 2019 17:48:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hq2de-0006s2-25 for guix-patches@gnu.org; Tue, 23 Jul 2019 17:48:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:55141) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hq2dd-0006rs-US for guix-patches@gnu.org; Tue, 23 Jul 2019 17:48:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hq2dd-0000Ev-Q9 for guix-patches@gnu.org; Tue, 23 Jul 2019 17:48:01 -0400 Subject: [bug#36555] [PATCH v4 3/3] tests: Add reconfigure system test. Resent-Message-ID: From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <87imsci9sj.fsf@sdf.lonestar.org> <87ef30i9fl.fsf@sdf.lonestar.org> <87y3129qsn.fsf@gnu.org> <87sgr9bziq.fsf@sdf.lonestar.org> <87pnmc7nt1.fsf@gnu.org> <8736j7nwcb.fsf@sdf.lonestar.org> <87muhfjm14.fsf@gnu.org> <87ftn63l7d.fsf@sdf.lonestar.org> <87v9w1zgon.fsf_-_@sdf.lonestar.org> <87y30v3qke.fsf@sdf.lonestar.org> <871rylrjt8.fsf_-_@sdf.lonestar.org> <87wogdq575.fsf_-_@sdf.lonestar.org> <87r26lq531.fsf_-_@sdf.lonestar.org> <87muh9q51e.fsf_-_@sdf.lonestar.org> <87wogc4v6e.fsf@gnu.org> <87zhl69box.fsf@sdf.lonestar.org> Date: Tue, 23 Jul 2019 23:47:05 +0200 In-Reply-To: <87zhl69box.fsf@sdf.lonestar.org> (Jakob L. Kreuze's message of "Mon, 22 Jul 2019 14:16:46 -0400") Message-ID: <87o91kzana.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: "Jakob L. Kreuze" Cc: 36555@debbugs.gnu.org Hello, zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) skribis: > Ludovic Court=C3=A8s writes: [...] >> I like to avoid exposing constructors so that one cannot =E2=80=9Cforge= =E2=80=9D >> invalid objects, but let=E2=80=99s see=E2=80=A6 > > Should I use @@ for this, perhaps? No, it=E2=80=99s not any better ;-), but anyway, let=E2=80=99s address this= later. >> (Once we=E2=80=99ve done that (guix graph) demonadification we discussed >> before, perhaps we can perform run =E2=80=98shepherd-service-upgrade=E2= =80=99 entirely >> on the =E2=80=9Cother side=E2=80=9D, and at that point we won=E2=80=99t = need to expose the >> =E2=80=98live-service=E2=80=99 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 =E2=80=98install-bootloader=E2=80=99 fails though? We = should make >> sure that the error is diagnosed, and that the output of >> =E2=80=98grub-install=E2=80=99 or similar is shown when that happens. I think you didn=E2=80=99t answer this specific question; thoughts? >> Note that there are now a few places where we call =E2=80=98built-deriva= tions=E2=80=99 >> without calling =E2=80=98show-what-to-build*=E2=80=99 first. That means = the UX might >> be pretty bad since one has no idea what=E2=80=99s being built. >> >> Furthermore, that means substitutes may not be up-to-date, leading to >> many =E2=80=9Cupdating substitutes=E2=80=9D messages and HTTP round trip= s (as happened >> with ). >> >> Last, doing several =E2=80=98build-derivations=E2=80=99 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 >> =E2=80=98show-what-to-build*=E2=80=99 once for =E2=80=98build-derivation= s=E2=80=99 call. >> >> What=E2=80=99s 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 =E2=80=98build-derivations=E2=80=99 calls is the same whether= it=E2=80=99s local or distant. What would make a difference is having a single script instead of three=E2=80=94i.e., one program that does: #~(begin (activate-system =E2=80=A6) (upgrade-services =E2=80=A6) (switch-system =E2=80=A6)) I think this program could even be added to the =E2=80=98system=E2=80=99 derivation=E2=80=94i.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=E2=80=99s =E2=80=98switch=E2=80=99 program. Perhaps this should be our horizon. WDYT? Thanks for your feedback! Ludo=E2=80=99.