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