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