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

newer
[arch-general] systemd and pm-utils

Yclept Nemo

23 Jul 2012 23 Jul '12

4:24 a.m.

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...

Show replies by date

Tom Gundersen

23 Jul 23 Jul

10:46 a.m.

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

On Mon, Jul 23, 2012 at 6:24 AM, Yclept Nemo 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

Leonid Isaev

3:48 p.m.

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

On Mon, 23 Jul 2012 12:46:52 +0200 Tom Gundersen wrote:

...

On Mon, Jul 23, 2012 at 6:24 AM, Yclept Nemo 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

Menachem Moystoviz

24 Jul 24 Jul

8:12 p.m.

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

On Mon, Jul 23, 2012 at 6:48 PM, Leonid Isaev wrote:

...

On Mon, 23 Jul 2012 12:46:52 +0200 Tom Gundersen wrote:

...
On Mon, Jul 23, 2012 at 6:24 AM, Yclept Nemo 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

Geert Hendrickx

28 Jul 28 Jul

6:53 a.m.

New subject: [arch-general] [RFC, after the fact] initscripts config

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!

4317

Age (days ago)

4322

Last active (days ago)

List overview

Download

4 comments

5 participants

participants (5)

Geert Hendrickx
Leonid Isaev
Menachem Moystoviz
Tom Gundersen
Yclept Nemo