Skip to content

Improvements to and potential finalisation of the Base Directory Specification

First things first, the Base Directory Specification is obviously built on an excellent premise and is something that software vendors should ideally take into consideration. However, in its present state, there are a fair few concerns with it from other software developers I have spoken to which may potentially hinder adoption, and I feel like it might be worth addressing these in the hopes of potentially finalising the spec, particularly with regards to $XDG_RUNTIME_DIR's (frankly insane) laundry list of requirements aside from its missing default, and the current confusing nature of $XDG_CONFIG_DIRS and $XDG_DATA_DIRS.

A few examples of the current sticking points and flaws in the spec were brought up once by the developer and maintainer of the init system Dinit, who writes the following:

"Files in this directory MAY be subjected to periodic clean-up. To ensure that your files are not removed, they should have their access time timestamp modified at least once every 6 hours of monotonic time or the 'sticky' bit should be set on the file."

That's a requirement that shouldn't be imposed, and the sticky bit isn't for the purpose given. There's no way Dinit will ever attempt to update the timestamp of its control socket every 6 hours, nor attempt to set the sticky bit on it. No sensible system would ever simply delete files on a 6-hourly basis. There's no justification for doing so, and no rationale given in the spec either. Asking applications to either abuse the sticky bit or update the timestamps is not going to go well. I doubt that many applications adhere to these requirements, and if the system really does delete the files every 6+ hours this probably leads to strange issues (that can be mostly be resolved by restarting the affected applications, but that sucks in terms of user experience, and for no good reason).

"If $XDG_RUNTIME_DIR is not set applications should fall back to a replacement directory with similar capabilities and print a warning message."

Dinit is not going to print a warning message for this scenario as there's no point in doing so.

"A specification that refers to $XDG_DATA_DIRS or $XDG_CONFIG_DIRS should define what the behaviour must be when a file is located under multiple base directories. It could, for example, define that only the file under the most important base directory should be used or, as another example, it could define rules for merging the information from the different files."

So there's no consistency between different applications regarding their treatment of this situation, which seems to be a pretty decent-sized hole in the spec, and makes it unclear what the purpose of multiple DATA_DIRS or CONFIG_DIRS is really supposed to be. Dinit uses XDG_CONFIG_HOME as a default base location for its service spec dir ($XDG_CONFIG_HOME/dinit) but doesn't search $XDG_CONFIG_DIRS and won't unless/until the semantics aren't cleared up, maybe.

Prior to this, the developer of the Xorg startup script sx says the following regarding $XDG_RUNTIME_DIR:

I had considered this approach in earlier iterations but eventually decided against it.

Ultimately because it relies on too many assumptions about the environment/system, such as assuming /run/user. The XDG_RUNTIME_DIR variable is quite an odd duck compared to the rest of the specification and certainly doesn't follow the spirit of it; the most notable distinction being that it has no well defined fallback and is required to be set, nevermind the laundry list of other incidental requirements.

If it were up to me I would remove XDG_RUNTIME_DIR from the XBDS entirely. It would be more appropriate to have it formalised under the umbrella of systemd instead and have them maintain its definition: https://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart

While I don't necessarily agree with outright removing XDG_RUNTIME_DIR, I do believe it could be reworked a bit in order to eliminate some of the more unusual requirements, and potentially have a default fallback value similar to the rest of the variables defined in the spec.

Lastly, some other sticking points I've personally had with the spec were the following:

  • There does not exist a named environment variable for the suggested $HOME/.local/bin executable path. Many adherents of the spec have suggested that there should be an $XDG_BIN_HOME or equivalent (say, $XDG_EXEC_HOME) to hold this path as a default and allow using an alternate path instead of "hardcoding" $HOME/.local/bin.
  • The spec does not currently take into consideration situations in which software such as a server daemon, typically running as another user such as root, may need to refer to another user's XDG_ locations, which is currently nigh-impossible due to the reliance on per-process environment variables.
  • The fact that the spec is still standing at version 0.8, as opposed to at least 1.0, has dissuaded some software vendors in the past from adhering to the spec due to the resulting implication that the spec may be "incomplete". For this reason, finalising the spec with everything mentioned so far might be worth considering.