[arch-general] [arch-dev-public] [RFC, after the fact] initscripts config
3) Personally this depends on the final rc.conf, is [1] or [2] going to be it? I don't enjoy visually collating options across rc.conf (terminal #1,vim) and rc.conf(5) (terminal #2,man). So if after actions (2), and (4), nothing remains but "esoteric" options, then sure, go ahead and do whatever you wish: remove them all or include everything. [1] http://projects.archlinux.org/initscripts.git/tree/rc.conf?id=ae28554e561517... [2] http://projects.archlinux.org/initscripts.git/tree/rc.conf?id=5b062674869c97... 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). 4.2) To be clear, is there going to be a separate configuration for the HARDWARECLOCK and TIMEZONE variables?
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. That in and of itself can generate much controversy. On one hand, it might be better to enforce a strict separation between configuration and code, thus requiring the removal of code into wrapper scripts. On the other hand, blurring such a line could while providing extensibility, in certain situations encourage faux-pas configurations better suited to wrapper scripts. Then is the faux-pas inherent to the programming language or the context of the configuration file? In my defense, I refer to [3] which lists many incorrect idioms. Also there is a sound way to read configuration files written in a programming language - simply evaluate the code. In any case, to preserve compatibility with systemd, the new files (/etc/vconsole.conf, /etc/locale.conf, /etc/hostname) should not contain bash. [3] mywiki.wooledge.org/BashFAQ/ 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 USE_BTRFS -> esoteric, removed for cosmetic reasons etc...
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
On Mon, 23 Jul 2012 12:46:52 +0200 Tom Gundersen <teg@jklm.no> wrote:
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.
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
On Mon, Jul 23, 2012 at 6:48 PM, Leonid Isaev <lisaev@umail.iu.edu> wrote:
On Mon, 23 Jul 2012 12:46:52 +0200 Tom Gundersen <teg@jklm.no> wrote:
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.
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
On Mon, Jul 23, 2012 at 12:46:52 +0200, Tom Gundersen wrote:
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.
What should it look like for people previously using "any other value" for HARDWARECLOCK? (for virtualization setups where there is no hardware clock) The manpage no longer mentions the "any other value" option, and hwclock(8) does not say anything about virtual systems either. Geert -- geert.hendrickx.be :: geert@hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!
participants (5)
-
Geert Hendrickx
-
Leonid Isaev
-
Menachem Moystoviz
-
Tom Gundersen
-
Yclept Nemo