XDG_CONFIG_DIRS an /usr/local/etc/xdg

[Peter White]

On Thu, Sep 16, 2021 at 02:49:40PM +0000, Bollinger, John C wrote:
> Your concerns seem to be focused mostly on how to deal with having
> multiple versions of the same application installed simultaneously.

Exactly.

> The challenges involved in making that work for applications that rely
> on XDG Base Directory are not tied to installation manner or location.

Well, they should be then. ;) It is a pretty common scenario and has
been thought of and accounted for in other (non/pre-XDG) software. I try
upstream versions on a regular basis, i.e. zsh (really only for testing)
or mpv which I run locally installed version of but do have the distro
version as fallback, in case there is breakage with a new upstream
version. It is as simple as changing PATH and the software the also
picks its config from the appropriate sysconf location "automagically".
Now, mpv hardcodes the location of its sysconf dir at compile time
accounting for PREFIX. Seems like that needs to happen with the
project I am thinking of here, which begs the question if there is
really any meaningful use for facilities like g_get_sysconfig_dirs(), if
one has to decide at compile time anyway.

> You should first consider whether you really want to have multiple
> versions at all.

Yes, very much so, it should always be possible to run a locally
installed version which takes precedence. I mean, look at /usr/local (or
/opt) in the Filesystem Hierarchy Standard. That is precisely the use
case they are there for. All that needs to be done to make that work is
configure PATH, which most distros already setup that way, i.e.:

	PATH=/usr/local/bin:/usr/bin

Plus, one cannot always uninstall the distro version without violating
dependencies of other packages, so the package manager refuses removal,
and rightly so.

> If you are sure you do, then you should furthermore
> distinguish between the case where you just want to test a different
> version and the case where you want to maintain multiple versions in
> parallel indefinitely.

I should not have to, see above. ;) Why install software to /usr/local
if it then goes out of its way to find sysconfig dirs *outside* the
PREFIX? The more I think about it the less I am thinking that querying
XDG_CONFIG_DIRS is the right thing to do, at runtime that is, because
one should expect it to point to the distro's /etc/xdg, where local
software has no business.

> > I have pondered this for a while now and could also not find
> > anything via search engine or on this list, so I figured I actually
> > ask the ones who wrote the spec.
> 
> I did not write the spec, but I have implemented it. I'm uncertain
> whether those who did write it hang around here.

I was hoping they would be, or is there a better way of contacting them?

> Anyway, your questions seem to fall more in the general system
> administration area than in the area of the spec itself.

I respectfully disagree, since it is a question about what should or
maybe should *not* happen at compile time or at runtime, respectively. I
am asking for a general way to make the software redistributable but
still installable locally, like virtually every software project makes
possible. The admin/user *should* have nothing more to do than making
sure that PATH is set correctly to have /usr/local take precedence, but
that is already taken care of in virtually every distro.

The way I understand it now, is that XDG_CONFIG_DIRS has its use *only*
at compile time for package maintainers, but that makes it a dud,
mostly, since that is what SYSCONFDIR can be used for and has been long
before the conception of the XDG spec.


Best,
PW

P.S.: Please reply to the list, so the headers stay intact. I almost did
not notice and would have replied to you privately. Also, please don't
break my formatting. I am trying to obey the netiquette of limiting line
length and quite frankly, so should you. ;)