XDG_CONFIG_DIRS an /usr/local/etc/xdg

[Peter White]

On Sun, Sep 19, 2021 at 12:19:33PM +0200, David Faure wrote:
> On jeudi 16 septembre 2021 18:48:41 CEST Peter White wrote:
> > But, /etc should be off limits for software in /usr/local, right?
> 
> I don't think this assessment is correct.
> 
> For instance, I certainly expect KDE software installed in any prefix, to 
> respect the global settings in /etc/xdg/kdeglobals

Why would software need to read that file? Granted, I know virtually
noting about KDE, but shouldn't there be a facility that makes those
values available by other means, i.e. environment variables, or
a settings daemon or whatever? And BTW, shouldn't that be
/usr/{,local/}share/kdeglobals [1]?

	> share/config/ ... A special case is "kdeglobals": this file is
	> 		    read by all KDE applications.

and then XDG_DATA_DIRS is the relevant env var which already has the
correct default, as you point out below. Now, I don't know why "config"
files would go anywhere other than ${PREFIX}/etc but that is apparently
what KDE deems the right place.

Anyhow, if one really needs to make /etc/xdg/kdeglobals available to
apps in /usr/local, then that is one special case that applies to KDE
only, and that is the only case I can think of right now. One can just
make that work like so:

# ln -s /etc/xdg/kdeglobals ${PREFIX}/etc/xdg/kdeglobals

> XDG_CONFIG_DIRS was modeled very much after XDG_DATA_DIRS,
> where I would have tons of other examples like: apps in /usr/local or anywhere 
> else should still see /usr/share, for e.g. /usr/share/mime which has the 
> mimetype definitions.

That is not the same as /etc. The well known behaviour, prior to XDG,
should not be broken for desktops and, as pointed out above, use the
share/.. hierarchy then or whatever, since this seems very much like a
KDE quirk to me and should not be baked into a standard that is supposed
to agnostic of the environment.

> And yes, the intent is definitely that they should be read at runtime,

Yes, to find some global settings, maybe, but to find its *own* rc-file?

> so that [advanced] users can install things in custom prefixes and make things 
> work by setting a few env vars.

That is not something for "advanced" users, /usr/local is *the* very
well known default for make. And the expectation is that everything
needed to run software installed by 'make install' is available *inside*
said prefix. Anything *else* is for advanced users that can just make it
work by providing the proper symlink(s), for instance.
Just look at the default PATH on any distro. It will contain
/usr/local/bin and that will take precedence over /usr/bin. So one does
not need to be "advanced" to run 'make && sudo make install' and then
just run the locally built software by entering its binary's name
without any further ado.

> What it seems to me, is that /usr/local/etc/xdg should simply be added to the 
> default value for XDG_CONFIG_DIRS.

Again, that breaks prior art. As was pointed out in this thread before,
the spec talks about "information" as opposed to files.

Picture this: Software "foobar" installed in /usr/local finds *file*
foobarrc in /usr/local/etc/xdg/foobar with *information*/setting A but
not B in there, it will go on and read /etc/xdg/foobar/foobarrc and use
setting B from there, if a distro provided version is also installed.
In turn, running the distro version would also prefer setting A in
/usr/local/etc/xdg/foobar/foobarrc despite there being A with a
*different* value in /etc/xdg/foobar/foobarrc. Setting A in the most
certainly made for a newer version of foobarrc in /usr/local could just
as well lead to a DoS of the distro version of foobar, because at the
time it was packaged the newer, now legal, value of A was illegal.
And, since setting B was deprecated in the meantime the local version
will also deny service.
How is that for a worst case? ;)

> It's inconsistent that XDG_DATA_DIRS
> defaults to /usr/local/share:/usr/share while XDG_CONFIG_DIRS defaults to only 
> /etc/xdg instead of /usr/local/etc/xdg:/etc/xdg

And there might be good reasons for that, as just outlined above, which
is why I would very much like some input from the original authors on
this topic.

The main question still remains without a clear answer: Who or what
should query XDG_CONFIG_DIRS and to what end? Regular software: should
it really use it to find and then read its very own config file(s), the
location of which being known at compile time anyways? Or is this for
getting *other* information about the environment which said software
has no other means of getting, like kdeglobals, for instance?

[1] https://userbase.kde.org/KDE_System_Administration/KDE_Filesystem_Hierarchy