[arch-dev-public] [RFC, after the fact] initscripts config
Hi guys, The controversy of the recent change to rc.conf took me by surprise (silly me). So, let appologise for not taking this to arch-dev-public first and let me go back in time, and present an RFC, so we can all agree on what to do and I'll make whatever changes necessary and push a new version to testing. It seems that there was no opposition to the change to crypttab (except for some minor details being discussed at arch-projects), so I won't comment on that. Current state of affairs: rc.conf is the central configuration file for all Arch-specific settings. It is emphatically not the only configuration file for basic system configuration (locale.gen, hosts, fstab, crypttab and inittab spring to mind). Some of the configuration in rc.conf already have their own configuration files shipped by upstream (HARDWARECLOCK and TIMEZONE in particular). The fact that these variables are configured in two places, which can get out of sync (most of the time without the admin even knowing about the second place) causes endless minor bugs. The systemd project has been working towards providing a common set of configuration files for all distributions (regardless of what init daemon they use). This has been done by taking input from all the distros that contribute to systemd, and trying to pick the good things from each distro and leaving out the bad. I have been making sure that these configuration files can support whatever setups our old configuration files currently do. Most recently I added support for keyfile-offset to the systemd crypttab format as that was the last blocker (in my opinion) before systemd's crypttab format could replace Arch's. I'd like to point out that getting these sorts of changes into the systemd project has been surprisingly easy. Initscripts and systemd both now support the same configuration formats (i.e. we can read the systemd format, and systemd can read ours). rc.conf is documented in its own manpage, cross-referenced with the systemd configuration files' manpages. What I propose: 1) Support all current and past configuration options in rc.conf in perpetuity (if for whatever reason something must be dropped, this will of course be announced in the normal way). This is for instance what we did with the old network syntax, that should still work just fine, even if it is marked as deprecated for a long time. This perpetual support will at least be the case in initscripts, I have no strong opinions about whether or not this should be done in systemd as well (probably not). 2) Deprecate the "harmful" configuration options from rc.conf (i.e. the ones that cause bugs), as they are clearly not Arch-specific, and have their own configuration files. The deprecation means removing them from the standard rc.conf and recommending against their use in rc.conf(5) as well as explaining how they should be configured instead. 3) Remove esoteric configuration options from rc.conf and only document them in the manpage. I don't feel strongly about this at all, and would be happy to revert it if people object. My reasoning here is that only experts should be changing them, so nothing a new user should need to be faced with. As I said, not a big deal. 4) This is (apparently) the controversial one, and this one I do feel strongly about: Embrace the systemd configuration files (/etc/vconsole.conf, /etc/locale.conf, /etc/hostname and /etc/modules-load.d/) fully and declare them to be the recommended standard. This means removing KEYMAP, CONSOLEFONT, CONSOLEMAP, LOCALE and HOSTNAME from the default rc.conf and recommending the alternative format in rc.conf(5). We would of course still support the old options. Justification of (4): a) This is in line with (at least my take on) the aim of rc.conf: these options are no longer Arch-specific, but rather something shared with many other distros. b) This is more KISS (of course this is purely subjective, but I'll put it out there anyway): one configuration file per type of options is simpler than mixing them all together. Why should networking and locale be configured in the same file? If we mix that, why don't we also add in fstab and the rest? c) The difference between the new and the old format for an end user is truly trivial. I appreciate people not liking this change, but anyone who claims that this is a major regression will not be taken seriously. Sorry. d) The new format does not require a bash interpreter to be read. This means that lots of things which were previously impossible will now be possible (reading and writing the configs from programs can now be done in a sound way). e) People who use more than one distro don't have to learn more than one format. f) Guides, howtos, documentation will now apply equally well to Arch as to the other major distros. g) Having a huge ecosystem working on and agreeing on these formats should be an obvious benefit. h) The major one: systemd is here to stay, more and more Arch devs and users switch to systemd and we will increasingly struggle to get enough testers and reviewers for initscripts. However, I really want to support initscripts as long as I can. To make this doable for me, we need to unify. We need to share code, configuration and behavior to make initscripts sustainable even with very few testers. You might argue that what we should do is to block systemd in order to support initscripts. However, I think that would be a huge error as systemd is simply too superior in every way, so preventing our users from using it is not doing anyone any favors. I must admit I'm a bit exasperated by the shortsightedness of most of the flames on BBS/IRC/MLs. So if you are going to veto this, please also outline an alternative long-term plan. Cheers, Tom
On 22 July 2012 22:59, Tom Gundersen <teg@jklm.no> wrote:
e) People who use more than one distro don't have to learn more than one format. f) Guides, howtos, documentation will now apply equally well to Arch as to the other major distros.
I support your position, Tom. Especially the two above are very strong points for me, personally. I think this got resistance simply because it was not out in the open for discussion *long enough*. You will also have resistance because some would like Arch to be "unique", even by some illogical means. -- GPG/PGP ID: C0711BF1
On Sun, Jul 22, 2012 at 5:43 PM, Rashif Ray Rahman <schiv@archlinux.org> wrote:
I think this got resistance simply because it was not out in the open for discussion *long enough*.
Yeah, that was a mistake. -t
Le 2012-07-22 10:59, Tom Gundersen a écrit :
h) The major one: systemd is here to stay, more and more Arch devs and users switch to systemd and we will increasingly struggle to get enough testers and reviewers for initscripts. However, I really want to support initscripts as long as I can. To make this doable for me, we need to unify. We need to share code, configuration and behavior to make initscripts sustainable even with very few testers. You might argue that what we should do is to block systemd in order to support initscripts. However, I think that would be a huge error as systemd is simply too superior in every way, so preventing our users from using it is not doing anyone any favors.
I must admit I'm a bit exasperated by the shortsightedness of most of the flames on BBS/IRC/MLs. So if you are going to veto this, please also outline an alternative long-term plan.
Cheers,
Tom
I am joining the party a little late. I do not use systemd, but I support and appreciate your efforts to improve our initscript. However, I think that most of dissatisfaction that was recently expressed is caused by the lack of clarity surrounding our plans about systemd. My understanding is that systemd is truly superior and will inevitably become our default system. On the other hand, our traditional init will need to lose some of his "personality" during a transition that might be short or long (not clear). In this context, I wonder why don't we avoid duplication of effort and move to systemd right away? If we consider that systemd is not yet ready for Arch, I wouldbe more comfortable if we had a clear plan and timeline for the future transition. Cheers, Stéphane
On Jul 25, 2012 2:04 PM, "Stéphane Gaudreault" <stephane@archlinux.org> wrote:
I do not use systemd, but I support and appreciate your efforts to improve our initscript. However, I think that most of dissatisfaction that was recently expressed is caused by the lack of clarity surrounding our plans about systemd.
My understanding is that systemd is truly superior and will inevitably become our default system. On the other hand, our traditional init will need to lose some of his "personality" during a transition that might be short or long (not clear). In this context, I wonder why don't we avoid duplication of effort and move to systemd right away?
If we consider that systemd is not yet ready for Arch, I wouldbe more comfortable if we had a clear plan and timeline for the future transition.
If there is a consensus to move to systemd, I would support that. However, I don't want to force a move. If a move should happen, I suggest waiting a bit longer until more unit files have been added to our various packages. And to allow some more time to see if problems crop up. Regardless of that, I think the current unification is the right thing to do. Even if we never switch to systemd, this greatly reduces the maintenance burden for me in the long run. Should we switch to systemd soon, I still think this has been worth while as it means the change will be more gentle on our users, and most importantly, it has given us the chance to verify that no functionality is lost. Are there any objections or suggestions for improvements to the current rc.conf+man page in testing? I'll wait a bit longer before pushing a final version (there are some minor improvements in git I'd like to include). Cheers, Tom
On Sun, Jul 22, 2012 at 4:59 PM, Tom Gundersen <teg@jklm.no> wrote:
What I propose:
1) Support all current and past configuration options in rc.conf in perpetuity (if for whatever reason something must be dropped, this will of course be announced in the normal way). This is for instance what we did with the old network syntax, that should still work just fine, even if it is marked as deprecated for a long time. This perpetual support will at least be the case in initscripts, I have no strong opinions about whether or not this should be done in systemd as well (probably not).
2) Deprecate the "harmful" configuration options from rc.conf (i.e. the ones that cause bugs), as they are clearly not Arch-specific, and have their own configuration files. The deprecation means removing them from the standard rc.conf and recommending against their use in rc.conf(5) as well as explaining how they should be configured instead.
3) Remove esoteric configuration options from rc.conf and only document them in the manpage. I don't feel strongly about this at all, and would be happy to revert it if people object. My reasoning here is that only experts should be changing them, so nothing a new user should need to be faced with. As I said, not a big deal.
4) This is (apparently) the controversial one, and this one I do feel strongly about: Embrace the systemd configuration files (/etc/vconsole.conf, /etc/locale.conf, /etc/hostname and /etc/modules-load.d/) fully and declare them to be the recommended standard. This means removing KEYMAP, CONSOLEFONT, CONSOLEMAP, LOCALE and HOSTNAME from the default rc.conf and recommending the alternative format in rc.conf(5). We would of course still support the old options.
Justification of (4): a) This is in line with (at least my take on) the aim of rc.conf: these options are no longer Arch-specific, but rather something shared with many other distros. b) This is more KISS (of course this is purely subjective, but I'll put it out there anyway): one configuration file per type of options is simpler than mixing them all together. Why should networking and locale be configured in the same file? If we mix that, why don't we also add in fstab and the rest? c) The difference between the new and the old format for an end user is truly trivial. I appreciate people not liking this change, but anyone who claims that this is a major regression will not be taken seriously. Sorry. d) The new format does not require a bash interpreter to be read. This means that lots of things which were previously impossible will now be possible (reading and writing the configs from programs can now be done in a sound way). e) People who use more than one distro don't have to learn more than one format. f) Guides, howtos, documentation will now apply equally well to Arch as to the other major distros. g) Having a huge ecosystem working on and agreeing on these formats should be an obvious benefit. h) The major one: systemd is here to stay, more and more Arch devs and users switch to systemd and we will increasingly struggle to get enough testers and reviewers for initscripts. However, I really want to support initscripts as long as I can. To make this doable for me, we need to unify. We need to share code, configuration and behavior to make initscripts sustainable even with very few testers. You might argue that what we should do is to block systemd in order to support initscripts. However, I think that would be a huge error as systemd is simply too superior in every way, so preventing our users from using it is not doing anyone any favors.
As the objections to my proposal were relatively muted, I'll take that as a consensus ;-) At Thomas' suggestion I added a new manpage: ArchLinux(7), which will point people to all the (old and new) config files people should be setting up on a first install. It is very rudimentary now, but I think it is best to just get it out there, and any patches to improve it for the next release will be very gratefully received at arch-projects@archlinux.org. The same goes, of course for the rc.conf manpage, which I changed quite a bit since the last release as well. To those who helped and gave feedback: thanks a lot! And to those who ended up in the flaming cross-fire, my apologies :-) Cheers, tom
participants (3)
-
Rashif Ray Rahman
-
Stéphane Gaudreault
-
Tom Gundersen