Previously, we were only adding profile-relative paths to XDG_CONFIG_DIRS
variable. That required very ugly hacks like
https://github.com/NixOS/nixpkgs/issues/33282#issuecomment-524550842
to be able to configure XDG stuff.
Now, we are prepending the variable with /etc/xdg, allowing us to
simply use `environment.etc."xdg/…"` options.
This change is needed because the order of profiles correlate to the
order in PATH, therefore "/etc/profiles/per-user/$USER" always appeared
after the system packages directories.
In the absence of XCURSOR_PATH, the function XcursorLibraryPath
in libXcursor will return a hardcoded value unsuitable for NixOS.
Some desktops as well as display managers in NixOS currently do
set XCURSOR_PATH, but there are combinations where neither does
(e.g. SDDM+XFCE), resulting in no cursor themes being available.
The new definition if XCURSOR_PATH is effectively the same as what
KDE's startkde currently does.
Fixes issue #21442.
My original reason to put it at the beginning of NIX_PATH was to allow
shipping a particular version <nixpkgs> with a channel. But in order to
do that, we can still let the channel expression ship with a custom
version of nixpkgs by something like <channel/nixpkgs> and the builder
of the channel could also rewrite self-references.
So the inconvenience is now shifted towards the maintainer of the
channel rather than the user (which isn't nice, but better err on the
side of the developer rather than on the user), because as @edolstra
pointed out: Having the channels of root at the beginning of NIX_PATH
could have unintended side-effects if there a channel called nixpkgs.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is very useful if you want to distribute channels (and thus
expressions as well) in a similar fashion to Debians APT sources (or
PPAs or whatnot).
So, for example if you have a channel with some additional functions
or packages, you simply add that channel with:
sudo nix-channel --add https://example.com/my-nifty-channel foo
And you can access that channel using <foo>, for example in your
configuration.nix:
{
imports = [ <foo/modules/shiny-little-module> ];
environment.systemPackages = with import <foo/pkgs> {}; [ bar blah ];
services.udev.extraRules = import <foo/lib/udev/mkrule.nix> {
kernel = "eth*";
attr.address = "00:1D:60:B9:6D:4F";
name = "my_fast_network_card";
};
}
Within nixpkgs, we shouldn't have <nixos> used anywhere anymore, so we
shouldn't get into conflicts.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Using pkgs.lib on the spine of module evaluation is problematic
because the pkgs argument depends on the result of module
evaluation. To prevent an infinite recursion, pkgs and some of the
modules are evaluated twice, which is inefficient. Using ‘with lib’
prevents this problem.
