This provides a more convenient syntax and allows easier overriding.
For example,
environment.etc = singleton
{ target = "vconsole.conf";
source = vconsoleConf;
};
can now be written as
environment.etc."vconsole.conf".source = vconsoleConf;
This is required to create a gschemas.compiled file with content
from all gschemas. Otherwise, gschemas.compiled will be taken
from a random package, and gsettings programs will not find what
they are looking for. I had to add this to get NetworkManager-applet
to work. You'll also have to add share/glib-2.0 to the pathsToLink
list.
Generating this in the activation script (along with gtk icons
etc), is not the nicest solution. But I have no real idea on
how to modularise it.
‘systemd-vconsole-setup’ by default operates on /dev/tty0, the
currently active tty. Since it puts /dev/tty0 in Unicode or ASCII
mode, if the X server is currently active when it runs, keys such as
Alt-F4 won't reach the X server anymore. So use /dev/tty1 instead.
This is broken because it requires restarting applications to see new
NSS modules. The proper way to handle NSS modules is through nscd.
See commit 554ae9908b.
Subtle: dhcpcd.service would call resolvconf during shutdown, which in
turn would start invalidate-nscd.service, causing the shutdown to be
cancelled. Instead, give nscd.service a proper reload action, and do
"systemctl reload --no-block nscd.service". The --no-block is
necessary to prevent that command from waiting until a timeout occurs
(bug in systemd?).
Unless we search the entire filesystem to do a chown *and* restart
existing processes owned by that user, there is no sensible way that
we can change uids/gids. So don't try.
Systemd's systemd-vconsole-setup.service reads locale and console
font/keymap settings from these files. In particular, it sets the
virtual console to UTF-8 mode depending on the LANG setting.
This removed the need for the kbd job.
resolvconf prefers a locally running BIND resolver over the forwarders; we just
have to tell it whether we have one or not. We use 'config.services.bind.enable'
to make that decision, assuming that people are not going to configure a local
BIND that won't respond to queries on 127.0.0.1. If we run into such a (weird)
case, then we'll need to introduce another variable for that purpose which can
be set independently from 'config.services.bind.enable'.
