From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:39274) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hq2pI-0003tG-2R for guix-patches@gnu.org; Tue, 23 Jul 2019 18:00:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hq2pH-0005gb-2K for guix-patches@gnu.org; Tue, 23 Jul 2019 18:00:04 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:55154) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hq2pG-0005gD-Ui for guix-patches@gnu.org; Tue, 23 Jul 2019 18:00:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hq2pG-0000ba-QZ for guix-patches@gnu.org; Tue, 23 Jul 2019 18:00:02 -0400 Subject: [bug#36738] [PATCH] guix deploy: Support '--no-grafts' and '--system' Resent-Message-ID: References: <87a7d9l2hw.fsf@member.fsf.org> <874l3eauda.fsf@sdf.lonestar.org> <87sgqx8z81.fsf@sdf.lonestar.org> <878ssovgw5.fsf@dustycloud.org> From: Ricardo Wurmus In-reply-to: <878ssovgw5.fsf@dustycloud.org> Date: Tue, 23 Jul 2019 23:59:11 +0200 Message-ID: <87o91kbefk.fsf@elephly.net> 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: cwebber@dustycloud.org Cc: 36738@debbugs.gnu.org, =?UTF-8?Q?=E5=AE=8B=E6=96=87=E6=AD=A6?= Christopher Lemmer Webber writes: > Jakob L. Kreuze writes: > >> zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) writes: >> >>> Great idea. I think that continuing to call the machine's >>> 'system' would be confusing if we introduced the >>> notion of a target architecture, because we use "system" to refer to >>> the target architecture in the rest of Guix's command-line tools. >>> Maybe it would make sense to rename the field to >>> 'os' or something similar, and use the 'system' field to specify the >>> target architecture instead? Any thoughs? >> >> Actually, I had a thought. Why should we make this explicit, when we >> could take an implicit approach and identify the target's architecture >> with 'remote-eval'? Ideally, we'll be probing the machines anyway to >> implement safety checks on the declaration, so why >> not just add this to our list of pre-deployment tests? >> >> Regards, >> Jakob > > Maybe a good idea... let me think. Is there any case where we start > taking actions *before* we might probe a machine that we can think of? I don=E2=80=99t know if this qualifies, but if =E2=80=9Cguix deploy=E2=80= =9D were to *create* a machine (e.g. on EC2 via the Guile AWS library) it wouldn=E2=80=99t be able= to probe it first. But in that case we would have full control over what the target would be, so no probing would be required. -- Ricardo