XDG_CONFIG_DIRS an /usr/local/etc/xdg

[Peter White]

On Thu, Sep 16, 2021 at 11:39:30AM -0400, Elsie Hupp wrote:
> > XDG_CONFIG_DIRS acts like PATH does: first match wins, which
> > I would not expect to happen with conffiles.
> 
> In general I believe the expectation is for the XDG variables with the
> plural suffix (i.e. ending in “S”) to return array values. String
> arrays in C are weird, but it’s possible that you have the option of
> checking each item in the array rather than just using the first one.

That is not a problem here. The software does the right thing. The
question is more like, if it should be querying XDG_CONFIG_DIRS at
runtime in the first place. I am more and more suspecting, that it
should not, or that there is little to no benefit in doing so and can
lead to unintended behaviour.

> https://docs.gtk.org/glib/func.get_system_config_dirs.html
> 
> So how to access subsequent array entries would probably depend on if or whether you’re using one of GObject’s other language bindings.
> 
> Looking at Qt’s implementation, by comparison, they have these values that look relevant:
> 
> > ConfigLocation	"~/.config", "/etc/xdg"
> > GenericConfigLocation	"~/.config", "/etc/xdg”
> > AppConfigLocation	"~/.config/<APPNAME>", "/etc/xdg/<APPNAME>"

Yes, XDG_CONFIG_HOME takes precedence, of course. Or what other point am
I missing?

> Basically if you have a preferred config directory (or an ordered list
> of preferred directories), you could check each directory on your own
> list against the directories returned by g_get_system_config_dirs(),
> or other define an algorithm creating an alternatively sorted array
> from the g_get_system_config_dirs() return values.

That seems a lot of hassle (at runtime, mind you) for questionable gain.

> It sounds like what you would want to do here is prefer any array
> value outside the user’s home directory and only use an array value
> inside the user’s home directory as a fallback.

No, of course *not*, the user's config takes precedence, always. ;)

> > I think that's why: you cannot write inside such a container, so system-
> > wide configs cannot be changed. XDG_CONFIG_HOME has the problem, that
> > one cannot provide a default for everyone, which is the purpose of a
> > system-wide config and it cannot be installed by make install, unless
> > each user installs the software to $HOME/.local. Now, that can't be
> > right. ;)
> 
> If you’re specifically trying to work within Flatpak, the Flathub Discourse might also be a good place to ask:

No, I don't. I am asking a general question. Software installation is as
easy as:
	make && sudo make install

But it should not make things harder for people, who do want to package
it, like flatpak for instance.


Best,
Peter