From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Raghav Gururajan" Subject: Re: Thoughts on making Guix even better Date: Sun, 01 Mar 2020 10:26:00 +0000 Message-ID: <4b94b57c9165e519542a5bb4748b91d0@disroot.org> References: <131d7d47e8e77a426a28013be0e063ff9de735a9.camel@student.tugraz.at> <24c65c56c37b309c108f75fb9e3e4681866e7fac.camel@student.tugraz.at> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:51353) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j8LnS-0008L9-9m for guix-devel@gnu.org; Sun, 01 Mar 2020 05:26:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j8LnR-0005sW-6z for guix-devel@gnu.org; Sun, 01 Mar 2020 05:26:06 -0500 Received: from knopi.disroot.org ([178.21.23.139]:53608) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j8LnQ-0005s7-KZ for guix-devel@gnu.org; Sun, 01 Mar 2020 05:26:05 -0500 In-Reply-To: <131d7d47e8e77a426a28013be0e063ff9de735a9.camel@student.tugraz.at> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Sender: "Guix-devel" To: Leo Prikler , guix-devel@gnu.org Hello Leo!=0A=0A> This is not as much a guix package vs. guix system issu= e as it is an=0A> issue of explicit manifests against implicit ones. If y= ou use guix=0A> package with manifests and without inferiors, you will ha= ve the same=0A> problem. Likewise, you can use inferiors in your config.s= cm to=0A> mitigate some of those issues. At least it works for the kernel= , but=0A> it should in theory also work for packages.=0A=0AI see.=0A=0A> = PS: What you're envisioning is probably a front-end, that obscures the=0A= > very existence of a config.scm by managing one that is just as verbose= =0A> as guix-generated manifests are. However, this is not really a=0A> s= olution as it fails to address the need for a (human-readable) initial=0A= > configuration. The interface would also be a pain to deal with as each= =0A> service comes with its own configuration record allowing arbitrary l= isp=0A> expressions that one would have to write on the command line.=0A= =0AI think we can still maintain the guix way of doing config.scm and als= o bring modularity. My thought is, what if we could split the operating-s= ystem procedures into smaller procedures, such as, kernel, system-wide pa= ckages, services etc. into separate procedures? So if a user passes the p= rocedure name to the `guix system reconfigure` command, then only that pr= ocedure is reconfigured. For example, we can reconfigure kernel of the sy= stem without reconfiguring packages and services.=0A=0AWhat do you think?= =0A=0ARegards,=0ARG.