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