On Sat, Jul 21, 2012 at 4:51 AM, Tom Gundersen wrote:

On Sat, Jul 21, 2012 at 8:48 AM, Evangelos Foutras wrote:

...

I find removing most of the variables to be confusing and would suggest that [1] and [2] get reverted.

I'm not going to revert them outright, but we can discuss individual options (some clearly must go, others are a matter of taste).

...

My counterargument is the nonexistence, in the previous rc.conf, of default options that would need to be changed in a way that is transparent to the user.

I guess I should have pointed out that I'd like a way to update the comments about each of the options frequently (mainly to add warnings or explanations as we realise them), but when the comments were in rc.conf that would create .pacnew files, which is annoying. I'd also like new users to have to read the manpage before they decide to use any of the discouraged options, so they will at least know the alternatives.

...

Moreover, stuff like TIMEZONE, LOCALE and MODULES should be included in rc.conf; nobody really wants to run their system with the default LOCALE=C, and quite a few people will want to load extra modules (in my case vboxnetflt), without messing around with other files (/etc/locale.conf) or adding variables back into rc.conf, respectively.

I agree that most people would want to configure /etc/locale.conf and /etc/vconsole.conf (or their equivalents in /etc/rc.conf). This is a matter of taste, but I'd really rather we start only using the two former files for this purpose. A benefit I did not mention yet is that they allow a lot more options than what rc.conf ever did.

As to modules: This should really not me necessary these days, and in the cases it is, it is something we should consider fixing. With kernel 3.5 the last of the mainline modules that I'm aware of (kvm) no longer needs to be specified manually.

In the case of virtualbox, I think the simplest solution here would be to load the needed modules whenever virtualbox is installed. I.e., ship a file with the virtualbox package (/usr/lib/modules-load.d/virtualbox.conf) containing

vboxnetadp vboxnetflt

(and whatever else is needed)

...

In conclusion, a) the existing rc.conf is already stripped down to the essential system configuration options, b) I like having a default structure of these options in rc.conf instead of adding them back in at random places (in rc.conf), c) if we want to shift the task of configuring the hostname/locale/keymap/etc to external files, it might be preferable to remove them completely from rc.conf instead of having multiple points of truth.

a) this is not the case. The current rc.conf contains several redundant and at least one harmful setting (HARDWARECLOCK).

b) fair enough, though does not seem like a major issue.

c) I'd like to do this in the long-run, but we can't just rip out the old support over night (see the old network settings or the crypttab changes for how I'd like these things to be done).

...

(The above is my view on this change after spending 10 minutes trying to figure out how I can load modules through /etc/modprobe.d, after I noticed that MODULES was removed from rc.conf. In my defense, I thought it could be similar to the time MOD_BLACKLIST was dropped. :p)

rc.conf(5) points to modules-load.d(5)[0].

-t

[0]: http://0pointer.de/public/systemd-man/modules-load.d.html

Tom: The concerns expressed by Evangelos and Tobias were some of the concerns I had when the push towards systemd started. Systemd is great if you are managing a large number of computers, but excessive overkill for one or two desktops with no server. The network setup is probably great for laptops also, but not in my instance. I get to learn to do it with iproute2. The simplest possible configuration for that setup is rc.conf. I'm not attempting to be a luddite, but something about this seems to violate the Arch KISS policy. Users of desktop systems shouldn't be forced into something like this. One of the reasons I chose Arch was the simplicity of setting up my system and not having some built in utility bork it for me. I find Arch much easier to set up and maintain than Fedora, Suse, Debian, Ubuntu, etc, etc, etc, and I wasn't forced in to their philosophy of setting up a "CORPORATE", yes I'm screaming, desktop. Currently Arch provides simple control mechanisms in central locations, and IMHO should stay that way. Please pardon my intrusion on a developer discussion, as I truly have no say in the matter. Just thought I'd toss in my 2 cents. Myra -- Life's fun when your sick and psychotic!