[arch-general] [arch-dev-public] [RFC, after the fact] initscripts config

[Menachem Moystoviz]

On Mon, Jul 23, 2012 at 6:48 PM, Leonid Isaev <lisaev at umail.iu.edu> wrote:
> On Mon, 23 Jul 2012 12:46:52 +0200
> Tom Gundersen <teg at jklm.no> wrote:
>
>> On Mon, Jul 23, 2012 at 6:24 AM, Yclept Nemo <orbisvicis at 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=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