On Mon, Jul 23, 2012 at 6:24 AM, Yclept Nemo <orbisvicis@gmail.com> wrote:
3) Personally this depends on the final rc.conf, is [1] or [2] going to be it? [1] http://projects.archlinux.org/initscripts.git/tree/rc.conf?id=ae28554e561517... [2] http://projects.archlinux.org/initscripts.git/tree/rc.conf?id=5b062674869c97...
At the moment it is [1], so if no one tells me otherwise, that's it.
4.1) Are we going to ship default (possibly empty) replacement configuration files, which currently may not exist on many systems, and add these to the backup array? This includes (/etc/vconsole.conf, /etc/locale.conf, /etc/hostname).
I'd be against it, as it seems pointless. But it would be Dave's decision.
4.2) To be clear, is there going to be a separate configuration for the HARDWARECLOCK and TIMEZONE variables?
There already are. That's the problem. HARDWARECLOCK is configured in the third line of /etc/adjtime (see hwclock(8)), TIMEZONE is configured by pointing the /etc/localtime symlink at what you want.
d) The new format does not require a bash interpreter to be read
4.d) I think this is a terrible justification. A programming language embedded in a configuration system grants a lot of possibilities.
It also makes it impossible to reason about. Or to parse from another language than what it was defined in.
Also there is a sound way to read configuration files written in a programming language - simply evaluate the code.
But there is no sound way to then change the options and write them back.
In any case, to preserve compatibility with systemd, the new files (/etc/vconsole.conf, /etc/locale.conf, /etc/hostname) should not contain bash.
These files can all be read by bash, but are strictly defined. This means we can know their format and update them in a sound way.
5) With the plethora of changes, each for different reasons, I think there is justifcation for a comprehensive news item summarizing changes to each variable: LOCALE -> /etc/locale.conf HARDWARECLOCK -> deprecated
Sure.
USE_BTRFS -> esoteric, removed for cosmetic reasons
Won't kill this one, but I get your point. -t