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 <[email protected]> On Behalf Of Peter White
Sent: Wednesday, September 15, 2021 11:44 PM
To: [email protected]
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
