XDG_CONFIG_DIRS an /usr/local/etc/xdg

[Peter White]

On Mon, Sep 20, 2021 at 03:28:09PM +0100, Simon McVittie wrote:
> 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.

Nobody said anything about XDG_CONFIG_HOME being ignored. In one of the
first responses I very much clarified, that user config wins, always.
And if the sysadmin wants to override the defaults: edit the rc file in
/usr/local/etc/<appname>. There are good reasons for stopping after said
files have been read and reading only those in XDG_CONFIG_HOME
afterwards, explicitly ignoring /etc.

> 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")

And basically you have it backwards. See my other post about a dead
simple way of reading configs that has been around for ages: read the
*most* important file *last*. That saves you from any fancy "merging" of
config files, because it is a cheap side effect of that approach.

The only thing that I do not want, is the sysconf of the distro version
being read.

> 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.

Again, see my worst case of there being an obsolete setting in /etc/xdg
and a new (formerly illegal) one in /usr/local/etc/xdg, which could DoS
both versions.

> > 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.

Yes, at *make* runtime. :-P But it does not make a whole lot of sense
*guessing* or asking, rather, where to find *my* config, especially when
there is no (spec compliant) way to only use the local version, since it
(XDG BD) very much demands "information" in less important locations be
considered as well. See the setting being obsolete and hence missing in
/usr/local/etc/xdg... but still in active use and necessary in /etc for
the older distro version.

To reiterate again, /usr/local is expected to override /, by
masking/overruling files which are present in both. First file match
wins, ignore the less important one(s).

> > 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).

Interesting approach, thanks for the hint. But I still see no prefix in
there. I am only concerned about system-wide etc/xdg.

To summarize: The only way I see is to either hard code the location of
sysconf(file/dir) or to run local applications through a wrapper that
forces the environment to ignore /etc/xdg, i.e.:
	$ env XDG_CONFIG_DIRS=/usr/local/etc/xdg <binary>

which is precisely what I would rather avoid, especially since every
user would have to do that on their system, if they compile from
upstream. Or upstream needs to provide said wrapper, which again is code
that should not have been necessary to begin with. :-/


Best,
PW