[arch-dev-public] [RFC, after the fact] initscripts config
teg at jklm.no
Thu Jul 26 18:20:55 EDT 2012
On Sun, Jul 22, 2012 at 4:59 PM, Tom Gundersen <teg at 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
> 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
> 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 at 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 :-)
More information about the arch-dev-public