XDG_CONFIG_DIRS an /usr/local/etc/xdg

[Simon McVittie]

On Mon, 20 Sep 2021 at 12:28:43 +0000, Peter White wrote:
> Why would XDG_CONFIG_DIRS need to contain ${PREFIX}/etc/xdg for that?
> The app pretty much already knows where it is supposed to find *its own*
> system-wide config. The location of which *should* be in
> ${PREFIX}/etc/xdg/<appname>/, yes, but one does not need to check
> XDG_CONFIG_DIRS for that at runtime.

If you are an app author and you want to look for defaults, or even
configuration, in a ${prefix}-relative path, great. Do that! Nobody is
stopping you from doing that.

However, if you want sysadmins to be able to override the defaults of
your app on a system-wide basis, or if you want users to be able to
override the defaults on a per-user basis, they will likely thank you
for using basedirs at runtime to do that, rather than inventing your
own mechanism that requires them to set extra environment variables or
otherwise learn how your app is different.

More concretely, this would be a perfectly reasonable search path to have,
if you want it;

- $XDG_CONFIG_HOME/myapp/myapprc at runtime
  (per-user overrides, "most important")
- $dir/myapp/myapprc for each $dir in $XDG_CONFIG_DIRS at runtime
  (user and/or sysadmin overrides)
- ${sysconfdir}/myapp/myapprc for compile-time ${sysconfdir}
  (installation-specific configuration)
- ${datadir}/myapp/myapprc for compile-time ${datadir}
  (fallback/defaults, "least important")

(Vulkan-Loader does something similar to this; dbus also does something
similar to this, but with the data "stack" instead of the config "stack".)

If you did something like that, it would work equally well for
--prefix=/usr/local and --prefix=/opt, and still allow users and sysadmins
to override the settings for myapp the same way they're familiar with for
other apps.

> It would make sense, though, to query XDG_CONFIG_DIRS at *compile time*

I don't think that makes sense. The point of environment variables is that
they are runtime-variable.

> And the more I think about it *and* seeing that no-one seems to ever set
> XDG_CONFIG_DIRS, which then defaults to /etc/xdg, this variable could
> just as well be renamed to the singular version XDG_CONFIG_DIR and only
> contain *one* value

No, that would be an incompatible change that would break pre-existing,
working configurations.

> There is only one XDG_CONFIG_HOME as well.

XDG_CONFIG_HOME has a dual role: it's the highest-precedence configuration
directory, and it's the place that automated per-user configuration-saving
saves modified configuration.

It's entirely valid for a user to do something like this:

    XDG_CONFIG_HOME=$HOME/.config
    XDG_CONFIG_DIRS=$HOME/dotfiles/xdg:/etc/xdg

with $HOME/.config as the path that is modified automatically when apps
save their configuration, and $HOME/dotfiles/xdg for configuration that
the user edits with a text-editor (perhaps stored in a version control
system).

    smcv