From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Prikler Subject: Thoughts on making Guix even better Date: Sun, 23 Feb 2020 18:14:58 +0100 Message-ID: <131d7d47e8e77a426a28013be0e063ff9de735a9.camel@student.tugraz.at> References: <24c65c56c37b309c108f75fb9e3e4681866e7fac.camel@student.tugraz.at> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:35750) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j5uqO-0002UH-Nb for guix-devel@gnu.org; Sun, 23 Feb 2020 12:15:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j5uqM-0007Zn-Q1 for guix-devel@gnu.org; Sun, 23 Feb 2020 12:15:04 -0500 Received: from mailrelay.tugraz.at ([129.27.2.202]:28552) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j5uqM-0007Qp-3G for guix-devel@gnu.org; Sun, 23 Feb 2020 12:15:02 -0500 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: guix-devel@gnu.org, raghavgururajan@disroot.org Hello Raghav! > Lets assume we have 5 packages in profile. Package 1, 3 and 5 has > non-critical > updates. Package 4 has non-critical update but it breaks. Package 2 > has > critical update (CVE). We can either upgrade all packages except > package 4 (or) > we can upgrade only package 2. > > Lets assume we have 5 services/packages in system. Package/Service 1, > 3 and 5 > has non-critical updates. Package/Service 4 has non-critical update > but it > breaks. Package/Service 2 has critical update (CVE). Now, when we > reconfigure > the system, all packages/services will upgrade, package/service 4 > will break > the system. We can of course do '--roll-back' and take the system to > previous > working state. But that will leave the system with critical > vulnerability. > Therefore, we cannot reconfigure package/service 2 or any other parts > of the > system, until the package/service 4 is fixed. This window/gap puts > guix system > at great risk and instability. This is not as much a guix package vs. guix system issue as it is an issue of explicit manifests against implicit ones. If you use guix package with manifests and without inferiors, you will have the same problem. Likewise, you can use inferiors in your config.scm to mitigate some of those issues. At least it works for the kernel, but it should in theory also work for packages. The problem with inferiors as a solution to this problem is, that it doesn't address the issues of services. You'd have to use the current service structure with an inferior-package, which is not always what you want, specifically when the introduction of a new field to that service causes an issue. In addition to that, finding all package references and patching them to not include some breaking package (say e.g. the newest mesa version, which depending on your graphics card may or may not cause issues) can be very tedious depending on what is referenced where. Perhaps a lookup-inferior-services procedure might help here. Overall, there are also some "not so fun" things when dealing with inferior packages. For one (car (lookup-inferior-packages ...)) is quite a mouthful, especially when you know you'll always want the first result or there is only one to begin with. I'd welcome a procedure to turn an inferior into a procedure that always returns the first match. IIRC inferior packages are also not always accepted as packages, but I'd welcome being proven wrong about that. You can also modularize guix system by wrapping each and every service in a module which you either re-export from guix proper or -- in case of some failure -- implement on your own. That's a lot of work however. TL;DR: You can "modularize" transactions with 'guix system' in the same way you modularize 'guix package -m' (the "-m" means "not modular" ;P). Regards, Leo PS: What you're envisioning is probably a front-end, that obscures the very existence of a config.scm by managing one that is just as verbose as guix-generated manifests are. However, this is not really a solution as it fails to address the need for a (human-readable) initial configuration. The interface would also be a pain to deal with as each service comes with its own configuration record allowing arbitrary lisp expressions that one would have to write on the command line.