From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: udev rules and system configuration Date: Tue, 05 Jul 2016 10:34:37 +0200 Message-ID: <8737no1o0y.fsf@gnu.org> References: <448fd23bfc5b716dadbaf46aac1b85ce@d4n1.org> <87vb0mdj4w.fsf@elephly.net> <87inwlhlgv.fsf@gnu.org> <87shvpe9kz.fsf@elephly.net> <87inwlbe43.fsf@gnu.org> <87twg5qnxf.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42792) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKLoa-0007dS-73 for help-guix@gnu.org; Tue, 05 Jul 2016 04:34:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKLoW-0004Fr-FK for help-guix@gnu.org; Tue, 05 Jul 2016 04:34:43 -0400 In-Reply-To: <87twg5qnxf.fsf@elephly.net> (Ricardo Wurmus's message of "Mon, 04 Jul 2016 20:05:16 +0200") 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: Ricardo Wurmus Cc: Daniel Pimentel , help-guix@gnu.org Hello! Ricardo Wurmus skribis: > Ludovic Court=C3=A8s writes: > >> Ricardo Wurmus skribis: > >>> Here=E2=80=99s 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 =E2=80=9C/etc/guix/system/udev/rules.d=E2= =80=9D then all >>> files therein would automatically be considered part of the system >>> configuration, maybe after adding =E2=80=9C/etc/guix/system=E2=80=9D as= a prefix path to >>> some new field in the =E2=80=9Coperating-system=E2=80=9D 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 >>> =E2=80=9C/etc/config.scm=E2=80=9D and modifying services manually. [...] > These files are not loaded at system runtime but upon running =E2=80=9Cgu= ix > system reconfigure=E2=80=9D. Their contents *at that time* would be embe= dded in > the configuration. Their state *at runtime* would not matter (just like > the contents of =E2=80=9Cconfig.scm=E2=80=9D don=E2=80=99t matter at runt= ime). > > The files would become part of the configuration in the store. Changing > them would always require the additional step of reconfiguring the > system. OK, I had misunderstood your suggestion. It doesn=E2=80=99t have the drawb= acks I mentioned. However, I don=E2=80=99t like the idea of having special directories that a= re automatically scanned. In my mind, it=E2=80=99s a problem similar to =E2= =80=9Cmacro hygiene=E2=80=9D: we should not scan files whose name does not appear in config.scm. >> However, what we can do is improve the interface. Things that come to >> mind: >> >> 1. Change or remove the =E2=80=98udev-rule=E2=80=99 procedure; we shou= ld 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 =E2=80=9Cconfig.scm=E2=80=9D users would need to co= py more than > just the GuixSD config file to duplicate the system state on another > machine. In this example we would need both =E2=80=9Cconfig.scm=E2=80=9D= and > =E2=80=9Cmy-udev-rule=E2=80=9D in the same directory. It=E2=80=99s similar to your idea, except that the file is explicitly named= in the object. If that helps, we could also allow users to specify a directory containing several rules, instead of just a single rule: (local-file "./my-udev-rule-directory") >> 2. Add a =E2=80=98extra-udev-rule=E2=80=99 procedure that you could us= e like this: >> >> (operating-system >> ;; =E2=80=A6 >> (services (extra-udev-rule (local-file "./my-udev-rule")) >> =E2=80=A6)) >> >> thus avoiding the verbose =E2=80=98modify-services=E2=80=99 stanza. >> >> 3. (Instead of #2) Introduce a =E2=80=98udev-rules=E2=80=99 field in >> =E2=80=98operating-system=E2=80=99, just like we do for firmware. >> >> WDYT? > > I don=E2=80=99t know. Although this would simplify configuration I don= =E2=80=99t really > like either of them for somewhat conflicting reasons. #3 gives special > treatment to udev rules (=E2=80=9CWhat about Xorg config snippets?=E2=80= =9D), and with > #2 it seems like an unnecessary implementation detail that this > =E2=80=9Cextra-udev-rule=E2=80=9D procedure is inside of the =E2=80=9Cser= vices=E2=80=9D field (=E2=80=9CHow come > this is a service?=E2=80=9D). > > I also feel that we should avoid adding =E2=80=9Cspecial=E2=80=9D syntax.= Actually, I > really like how generic this whole =E2=80=9Cmodify-services=E2=80=9D busi= ness is. It=E2=80=99s > just a little too verbose to be user-friendly, in my opinion. I sympathize with that. In fact, translates to a graph. The whole thing is just =E2=80=9Csyntax.=E2=80=9D I would like to have a more formal way to describe this translation. I think this would allow us to fearlessly add or remove fields to . But I don=E2=80=99t know how to achieve it. In the meantime, we should still address the usability issue that you raised, which is why I made these suggestions. Thoughts? Thank you, Ludo=E2=80=99.