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.
(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.)
> 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.
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).
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.
smcv
