XDG_CONFIG_DIRS an /usr/local/etc/xdg

[David Faure]

On dimanche 19 septembre 2021 16:57:22 CEST Peter White wrote:
> 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? 

Well, that's the point of config files, to be read by software, isn't it?

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

You want one environment variable per setting in that file? That doesn't 
scale. A settings daemon might be what gnome does, it doesn't mean that all 
other free desktops want to have such an architecture. Surely reading files is 
still allowed in 2021?

> And BTW, shouldn't that be /usr/{,local/}share/kdeglobals [1]?

No, config files don't go to XDG_DATA_DIRS.

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

The above documentation is really outdated, it says "kde 3" in many places,
it predates the XDG base dir spec (at least, its use by KDE).

> 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

I don't believe so. As I said, everyone agrees that /usr is available to apps 
in /usr/local (since that's the default value for XDG_DATA_DIRS)
so why not do the same with config dirs?

> and that is the only case I can think of right now. 

There are lots of other files in /etc/xdg...
For instance /etc/xdg/user-dirs.conf which is not KDE specific at all.

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

Please stop saying this is a KDE quirk. It's the XDG base spec that defines 
/etc/xdg to be the default location for systemwide config files,
while KDE was using historically share/config as you found out.

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

An app's own configuration is combination of the system wide defaults
(in /etc/xdg), its own installed defaults (in $PREFIX/etc/xdg), and the user's 
preferences (in $XDG_CONFIG_HOME). This assumes the XDG_CONFIG_DIRS is
set to contain the first two values, as is customary when using a custom 
prefix since the exact same thing has to be done with XDG_DATA_DIRS.

The only case where one doesn't have to add $PREFIX to XDG_DATA_DIRS
is the case where $PREFIX is /usr/local/, which is why I'm suggesting doing 
the same with XDG_CONFIG_DIRS by adding /usr/local/etc/xdg as a default value.

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

I know, that's what I'm saying.
By custom I mean really custom (e.g. /opt or $HOME/install or whatever).

> And the expectation is that everything
> needed to run software installed by 'make install' is available *inside*
> said prefix. 

Agreed. Hence /usr/local/etc/xdg.

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

Agreed, hence my suggestion.

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

Bugfixing is about changing behaviour indeed, but for the better.

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

That's the point of layering config files, yes.
You could add ~/.config/foobarrc to this sentence, it's a 3-layers view of the 
configuration.

> 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? ;)

You can cook up a similar scenario with /usr/share and /usr/local/share,
and yet I don't remember anyone ever having a problem with the distro version 
of an application picking up a wrong version of a file in /usr/local/share.

I think the idea was that one would not install the same app into /usr and 
/usr/local. It was rather about making things work out of the box in both 
prefixes, for different apps.

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

Good luck. At least I'm pretty sure Waldo doesn't read this list.

But one thing is for sure: if there's a reason, it's not the fact that config 
files would be layered, because that's the exact reason why XDG_CONFIG_DIRS is 
a set of dirs and not just one. And I remember that at the time, there was a 
strong use case for user groups sharing similar defaults, so the whole point 
was to set things up like /opt/admins/etc/xdg:/etc/xdg for some people
and /opt/endusers/etc/xdg:/etc/xdg for other people.
(and similar with XDG_DATA_DIRS)
Because /etc/xdg isn't /usr/etc/xdg, the lack of /usr/local/etc/xdg
was overlooked.

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

Regular software also uses libraries, which also have to find their own config 
files. "Known at compile time" leads to non-relocatable installations, which 
is rather restrictive for some use cases.

Here's a definitive answer from the KDE side at least: *yes*, "regular 
software" uses XDG_CONFIG_DIRS and XDG_CONFIG_HOME to find all the config 
files it's looking for (both in the application code and in the library code).

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5