On Mon, Jul 23, 2012 at 6:48 PM, Leonid Isaev <lisaev@xxxxxxxxxxxx> wrote: > On Mon, 23 Jul 2012 12:46:52 +0200 > Tom Gundersen <teg@xxxxxxx> wrote: > >> On Mon, Jul 23, 2012 at 6:24 AM, Yclept Nemo <orbisvicis@xxxxxxxxx> 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=ae28554e561517815c07330b2b7d5ee5de2f6dc7 >> > [2] >> > http://projects.archlinux.org/initscripts.git/tree/rc.conf?id=5b062674869c97018871b1f91c0b22d27ae900f7 >> >> 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. > > I wonder if there a need for TIMEZONE as a config variable at all (whereever > it is located, as opposed to an install-time setting), especially if it is > recommended to be left empty? > >> >> >>>>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 > > > > -- > Leonid Isaev > GnuPG key: 0x164B5A6D > Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D I have no problem with removing the options, however I agree with Yclept in that decreasing the expressive power of the configuration file is both unnecessary and counterproductive. While a bash script may not be the best configuration format, moving to an ini-style format would hurt those who require being able to dynamically specify configuration variables. Note - I myself wouldn't be affected by decreasing the power of the format, but I can well imagine people raising a hue and cry over it. Just my 2c M
