Arch Linux

submitted to wrong project.

rc.conf being a bash script is the source of all my problems. I'm afraid your suggestion would cause even more headache, as it would make it even more difficult to figure out where something is being defined. Imagine trying to read the config files from a third-party tool which is not a bash script. The most recent example is login-shells trying to read /etc/profile.d/locale.sh which in turns sources rc.conf. If your login-shell is not bash compatible you are in trouble. Another example is that I added rc.conf compatibility to systemd, and this would become endlessly more complicated if we allow secondary files (and not just config files, but bash scripts). A future example (maybe it already exists) might be gui configuration tools that should be able to write to and read from rc.conf.

I understand your problem though, and I'd be interested in working with you to solve it. My suggestion for solving it would be:

Many of the variables in rc.conf can be defined in their "native" or distro-independent (read "systemd") location, so all you'd have to do is to make sure they are unset in rc.conf and configure them elsewhere. In that case you'll have (roughly) one file per variable, and they will not be bash scripts, so automating configuration should be easy. This is the current situation:

LOCALE: set LANG in /etc/locale.conf instead (http://0pointer.de/public/systemd-man/locale.conf.html)
DAEMON_LOCALE: cannot be set elsewhere
HARDWARECLOCK: set the third line in /var/lib/hwclock/adjtime, assuming /var is on the root partition (man hwclock).
TIMEZONE: symlink /etc/localtime to your zoneinfo file yourself (man timezone)
KEYMAP/CONSOLEFONT/CONSOLEMAP: cannot be set elsewhere (but I'd accept a patch for http://0pointer.de/public/systemd-man/vconsole.conf.html)
USECOLOR: cannot be set elsewhere
MODULES: cannot be set elsewhere (but I'd accept a patch for http://0pointer.de/public/systemd-man/modules-load.d.html if it follows the style of what we do with sysctl and tmpfiles)
UDEV_TIMEOUT: cannot be set elsewhere, but udev would accept a patch for doing this in /etc/udev/udev.conf
USE{DMRAID,BTRFS,LVM}: cannot be set elsewhere (should go away one day once upstream gets their acts together)
HOSTNAME: cannot be set elsewhere (but I'd accept a patch for http://0pointer.de/public/systemd-man/hostname.html)
interfaces/...= cannot be set elsewhere, use a proper networking solution
NETWORK_PERSISTS: cannot be set elsewhere, but should go away, i need to look into it, patches/explanations welcome
DAEMONS: cannot be set elsewhere

What do you think?

A couple of (untested) patches for hostname and vconsole.conf support: https://github.com/teg/initscripts-arch/commits/master.

I'll add module-load.d support if there is demand for it, but that'll take a bit longer. If someone provide patches I'll probably include them in the next release (~one month from now), otherwise I'll get to it when I have time.

Sorry for the late answer -- The main reason why I started this request is because of the DAEMONS=() array, which is of special interest for automatic editing. If you think that this one can be moved out of rc.conf as well soon and continue moving out stuff, then this might be a solution.

Hmm... I feel your pain. I think, however, that DAEMONS is the only thing I'd be opposed to moving out. In a world where rc.conf was allowed to only contain DAEMONS, could you not just run it through a bash interperter to get the daemons array out, then manipulate it in your tool, and write a new rc.conf with your new DAEMONS array?

This means your tool would destroy any custom bash magic the user has put in rc.conf, but if you move out most other stuff, this might not be so bad? Maybe it would be worth declaring that bash-magic is frowned upon in rc.conf?

I think the best way forward is to write a suggestion to arch-projects@archlinux.org, and gauge everyone's mood on the topic.

I'd even think about changing rc.conf to cconfig style (what bernstein and fefe use as well):
cconfig only knows about flat files without the need for parsing.

Thus, we could restructure (and make everything WAY MORE SIMPLE (</capslock>)) it as follows:

/etc/rc.conf.d/daemons: \n seperated list of stuff to start, supporting @ and ! as it is right now
/etc/rc.conf.d/*: same for the rest, no \n seperation if it is only a single value.

I think I'll drop a longer mail to arch-projects this evening describing the idea more in detail.

@telmich: note that we already support much of <http://0pointer.de/public/systemd-man/> (and they are following the style you propose I think), and we will only consider adding our own config format for things that could not possibly be shared with other distros (and then only very reluctantly).

I agree in principle that having config files not be bash would be nice, but I also agree with those who are reluctant to change things. At the end of the day, I guess I'll be the easiest to convince, but the other's might need a more convincing argument / use-cases.