XDG_CONFIG_DIRS an /usr/local/etc/xdg

[Peter White]

On Mon, Sep 20, 2021 at 03:06:06PM +0100, Simon McVittie wrote:
> On Thu, 16 Sep 2021 at 04:44:17 +0000, Peter White wrote:
> > I am having a hard time finding documentation about the best way to make
> > locally installed software recognize its config dir in
> > /usr/local/etc/xdg.
> 
> One high-level approach to this is: give it sensible defaults, so that it
> will work correctly with an empty /etc, and don't install anything to
> ${sysconfdir}/etc/xdg from the package's build system.

This seems orthogonal to the problem at hand. I usually expect an rcfile
in /etc, or /usr/local/etc for that matter, as an editable working
"example". There are apps that have different defaults than are set in
the shipped config files residing in /etc.

> (Those defaults can be in a file in ${datadir} with the same syntax as the
> configuration file and a comment that says "do not modify, copy to /etc/xdg
> and modify the copy instead", if you want - that's a common approach.)

Yes, I see that a lot, as in /usr/local/share/doc/<appname/examplerc.
Config should not be read from anywhere other than ../etc and
XDG_CONFIG_HOME.

> > One might also think:
> > 
> >     # echo XDG_CONFIG_DIR=/usr/local/etc/xdg:/etc/xdg >> /etc/environment
> > 
> > could be the solution, but I believe that can lead to some unexpected
> > behaviour, when the user also has the distro counterpart of said
> > software installed, i.e. when they installed the local version to test
> > it against the distro version. If they then only change PATH to either
> > prefer the local or the distro version, the latter would also pick the
> > config which is only meant for the local one. The distro version might
> > be outdated an contain obsolete settings.
> 
> Yes. The same is true for XDG_DATA_HOME (defaulting to ~/.config/myapp):
> if you have myapp version 1 installed from a distro and myapp version 2
> installed locally, ~/.config/myapp affects both.

Good point, *but* I do not expect the local version to also read /etc/...
It should really only read one user config location and the system wide
one in /usr/local/etc/xdg but never its equivalent in /etc. The latter
is for the distro version. This way I only need to put those settings I
want to change on a per-user basis in XDG_CONFIG_HOME and thus reduce
the probability for conflict between version, if I ever need to run the
distro version. That one can have old settings all it wants in /etc,
since they (*should*) get ignored by the version in ${PREFIX}
(/usr/local).

> If that is unacceptable for your design, then either don't exclusively use
> the XDG basedirs for configuration, or use a versioned directory so that
> each major version will find the most appropriate directory (like the
> way GTK 2, 3 and 4 use $XDG_CONFIG_HOME/gtk-2.0, etc. to allow for the
> format and semantics of their configuration to diverge if necessary).

Well, we opted for simply hard coding the location to the sysconfig file
is expected to be in at compile time, i.e.
SYSSCONFFILE=${PREFIX}/etc/xdg/<appname>/<appname>rc

and a CPP directive which gets set at compile time.

This was the only sane way to get actually predictable behaviour. The
main devs of the project in question seemed rather surprised when I told
them that their app did not do as they thought on my box, since I do
have the distro version installed and they mistakenly put their
sysconfig in the wrong place and the distro version kicked in, when in
fact it should have found nothing, since I still very much expect /etc
to be off limits for anything /usr/local, except for getting information
about the environment, which I still think it should get by other means
than snooping in and *parsing* files in /etc/xdg.

> It is OK to read other locations like /etc/myapp, /usr/local/etc/myapp,
> /usr/share/myapp or /usr/local/share/myapp before or after XDG_CONFIG_HOME
> and XDG_CONFIG_DIRS - or even in between them, if that's what makes most
> sense.

That directly contradicts the spec, does it not? The order is set by
importance, XDG_*_HOME being the most important one. And why would there
be active *config* information in /usr/{,local/}share? Those are for
"data". Configs belong in etc.


Best,
PW