From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: udev rules and system configuration Date: Mon, 04 Jul 2016 20:05:16 +0200 Message-ID: <87twg5qnxf.fsf@elephly.net> References: <448fd23bfc5b716dadbaf46aac1b85ce@d4n1.org> <87vb0mdj4w.fsf@elephly.net> <87inwlhlgv.fsf@gnu.org> <87shvpe9kz.fsf@elephly.net> <87inwlbe43.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56482) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bK8FL-0008UI-49 for help-guix@gnu.org; Mon, 04 Jul 2016 14:05:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bK8FG-0008W5-TN for help-guix@gnu.org; Mon, 04 Jul 2016 14:05:26 -0400 In-reply-to: <87inwlbe43.fsf@gnu.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: Daniel Pimentel , help-guix@gnu.org Ludovic Courtès writes: > Ricardo Wurmus skribis: >> Here’s an idea, which might be bad: how about adding a feature to load >> and merge a directory tree of configuration files as they are? For >> example, if I had a directory “/etc/guix/system/udev/rules.d” then all >> files therein would automatically be considered part of the system >> configuration, maybe after adding “/etc/guix/system” as a prefix path to >> some new field in the “operating-system” declaration. >> >> I have a feeling that this will be considered a bad idea, but it also >> seems to me that it would make the configuration of some parts of the >> system easier than embedding file contents as strings in variables in >> “/etc/config.scm” and modifying services manually. > > It’s a bad idea! :-) > > Seriously, I think having a directory that is automatically picked up is > a bad idea in the sense that it would defeat one of the main goals of > GuixSD, which is to support reproducibility. The hypothetical > /etc/guix/udev directory would not be controlled by GuixSD, so rolling > back wouldn’t be enough to return to the previous state, copying the > GuixSD config file wouldn’t be enough to duplicate the system state on > another machine, and so on. These files are not loaded at system runtime but upon running “guix system reconfigure”. Their contents *at that time* would be embedded in the configuration. Their state *at runtime* would not matter (just like the contents of “config.scm” don’t matter at runtime). The files would become part of the configuration in the store. Changing them would always require the additional step of reconfiguring the system. > However, what we can do is improve the interface. Things that come to > mind: > > 1. Change or remove the ‘udev-rule’ procedure; we should be using > file-like objects instead, so one could store them alongside > config.scm and write: > > (local-file "./my-udev-rule") Is this really so different from the bad idea I proposed? As soon as we load files outside of “config.scm” users would need to copy more than just the GuixSD config file to duplicate the system state on another machine. In this example we would need both “config.scm” and “my-udev-rule” in the same directory. The bad idea still requires a user to tell Guix to load udev rule files from somewhere. The difference is that instead of loading files individually by name it would load *all* rules from the directory. I guess it’s not very different form what you propose in #3, actually. > 2. Add a ‘extra-udev-rule’ procedure that you could use like this: > > (operating-system > ;; … > (services (extra-udev-rule (local-file "./my-udev-rule")) > …)) > > thus avoiding the verbose ‘modify-services’ stanza. > > 3. (Instead of #2) Introduce a ‘udev-rules’ field in > ‘operating-system’, just like we do for firmware. > > WDYT? I don’t know. Although this would simplify configuration I don’t really like either of them for somewhat conflicting reasons. #3 gives special treatment to udev rules (“What about Xorg config snippets?”), and with #2 it seems like an unnecessary implementation detail that this “extra-udev-rule” procedure is inside of the “services” field (“How come this is a service?”). I also feel that we should avoid adding “special” syntax. Actually, I really like how generic this whole “modify-services” business is. It’s just a little too verbose to be user-friendly, in my opinion. ~~ Ricardo