XDG_CONFIG_DIRS an /usr/local/etc/xdg

Bollinger, John C John.Bollinger at STJUDE.ORG
Thu Sep 16 14:49:40 UTC 2021


Dear Peter,

XDG Base Directory specifies the significance of certain environment variables.  How those obtain their values is out of the specification's scope. It varies with execution environment and with execution context.

Some of the tools at your disposal on various systems are:

 - The /etc/environment (since you mentioned it).  This is little used in my experience, fairly inflexible, and applicable only to certain execution environments and contexts
 - System-wide shell configuration scripts.  Different shells have different ones. For Bash, for example, these would be /etc/profile and /etc/bashrc
    - Some environments (RedHat- and Debian-family Linuxes, for example) augment this with a drop-in system revolving around files in /etc/profile.d/
    - These have access to the full language of the corresponding shell, and thus have a lot of flexibility
 - Per-user shell configuration scripts (~/.bash_profile and ~/.bashrc for Bash, for example)
    - These, too, have the flexibility offered by the corresponding shell language
    - They are also user-specific, which is important on multi-user systems
    - But of course, each user needs to manage their own
 - Scripts that launch new shells with special environment configurations
 - The environment modules system
 - Wrapper scripts around selected binaries, to launch them with modified or augmented environment
   - These are application-specific instead of user-specific

> So I guess, my first question is, if XDG_CONFIG_DIRS is even meant to be used by locally installed software, its default seems to suggest otherwise? Or is this maybe just an oversight in the spec?

The Base Directory spec is agnostic to the source and manner of installation of software that makes use of it.  You can use any of a variety of mechanisms to ensure that the wanted config directories are specified therein.  In any case, you generally do not have a choice in whether a particular third-party application uses Base Directory to locate its files.  I see no particular oversight in the spec in this regard.

Your concerns seem to be focused mostly on how to deal with having multiple versions of the same application installed simultaneously.  The challenges involved in making that work for applications that rely on XDG Base Directory are not tied to installation manner or location.  You should first consider whether you really want to have multiple versions at all.  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 would approach the two differently, and in particular, I would arrange for better isolation in the test-only case than you seem to be describing.

> 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.  Anyway, your questions seem to fall more in the general system administration area than in the area of the spec itself.


Regards,
John Bollinger

-----Original Message-----
From: xdg <xdg-bounces at lists.freedesktop.org> On Behalf Of Peter White
Sent: Wednesday, September 15, 2021 11:44 PM
To: xdg at lists.freedesktop.org
Subject: XDG_CONFIG_DIRS an /usr/local/etc/xdg

Caution: External Sender. Do not open unless you know the content is safe.


Dear list,

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. Of course, the quick and easy answer could be:

    $ env XDG_CONFIG_DIRS=/usr/local/etc/xdg foobar

But that is not something one can ask their users if they install software from an upstream repository. I believe XDG_CONFIG_DIRS is unset on most systems and thus defaults to /etc/xdg, i.e. returned by g_get_system_config_dirs(), so most people would have to set it manually to make software in /usr/local pick up its config from there, which it should IMO.

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.
>From what other software (i.e. a shell) does, I believe the correct way would be to use the /usr/local/etc/xdg when running a local version and /etc/xdg when running the distro version, if I am not mistaken.

So I guess, my first question is, if XDG_CONFIG_DIRS is even meant to be used by locally installed software, its default seems to suggest otherwise? Or is this maybe just an oversight in the spec? I'd find that hard to believe, given that it's been around for quite a while now, so my thought process may very well be flawed here.

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. ;)


Best,
PW

________________________________

Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer


More information about the xdg mailing list