From: Ricardo Wurmus <rekado@elephly.net>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Daniel Pimentel <d4n1@d4n1.org>, help-guix@gnu.org
Subject: Re: udev rules and system configuration
Date: Mon, 04 Jul 2016 20:05:16 +0200 [thread overview]
Message-ID: <87twg5qnxf.fsf@elephly.net> (raw)
In-Reply-To: <87inwlbe43.fsf@gnu.org>
Ludovic Courtès <ludo@gnu.org> writes:
> Ricardo Wurmus <rekado@elephly.net> 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
next prev parent reply other threads:[~2016-07-04 18:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-03 22:12 Microscheme failed Daniel Pimentel
2016-07-04 6:14 ` Ricardo Wurmus
2016-07-04 8:10 ` Ludovic Courtès
2016-07-04 14:55 ` udev rules and system configuration (was: Microscheme failed) Ricardo Wurmus
2016-07-04 15:46 ` udev rules and system configuration Ludovic Courtès
2016-07-04 18:05 ` Ricardo Wurmus [this message]
2016-07-05 8:34 ` Ludovic Courtès
2016-07-14 14:22 ` Microscheme failed Daniel Pimentel
2016-07-04 12:30 ` Daniel Pimentel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87twg5qnxf.fsf@elephly.net \
--to=rekado@elephly.net \
--cc=d4n1@d4n1.org \
--cc=help-guix@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).