From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:38446) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hpxvP-0004vq-0k for guix-patches@gnu.org; Tue, 23 Jul 2019 12:46:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hpxvO-0001qf-1h for guix-patches@gnu.org; Tue, 23 Jul 2019 12:46:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:54953) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hpxvN-0001qW-Sx for guix-patches@gnu.org; Tue, 23 Jul 2019 12:46:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hpxvN-0006FT-QS for guix-patches@gnu.org; Tue, 23 Jul 2019 12:46:01 -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> From: Christopher Lemmer Webber In-reply-to: <87sgqx8z81.fsf@sdf.lonestar.org> Date: Tue, 23 Jul 2019 12:45:46 -0400 Message-ID: <878ssovgw5.fsf@dustycloud.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: "Jakob L. Kreuze" Cc: 36738@debbugs.gnu.org, =?UTF-8?Q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 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? How would we also probe it? Is there a chance of our probing behaving incorrectly? That would also be bad, if so. Another route is to have the user specify what architecture they think the machine has, and instead the probing is a "safety check"?