From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:42762) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hph7H-0003w8-D2 for guix-patches@gnu.org; Mon, 22 Jul 2019 18:49:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hph7F-0002WJ-9k for guix-patches@gnu.org; Mon, 22 Jul 2019 18:49:11 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:53146) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hph78-0002N9-9z for guix-patches@gnu.org; Mon, 22 Jul 2019 18:49:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hph78-0008Nh-5r for guix-patches@gnu.org; Mon, 22 Jul 2019 18:49:02 -0400 Subject: [bug#36738] [PATCH] guix deploy: Support '--no-grafts' and '--system' Resent-Message-ID: From: zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) References: <87a7d9l2hw.fsf@member.fsf.org> <874l3eauda.fsf@sdf.lonestar.org> Date: Mon, 22 Jul 2019 18:46:06 -0400 In-Reply-To: <874l3eauda.fsf@sdf.lonestar.org> (Jakob L. Kreuze's message of "Mon, 22 Jul 2019 12:48:01 -0400") Message-ID: <87sgqx8z81.fsf@sdf.lonestar.org> MIME-Version: 1.0 Content-Type: text/plain 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: =?UTF-8?Q?=E5=AE=8B=E6=96=87=E6=AD=A6?= Cc: 36738@debbugs.gnu.org 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