On Sun, Jul 22, 2012 at 4:59 PM, Tom Gundersen <[email protected]> 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 [email protected]. 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
