Talk:XDG Base Directory

From ArchWiki
Jump to: navigation, search


Has anyone looked at XDG Directories for emacs? Ben Creasy (talk) 02:40, 15 July 2015 (UTC)

It seems that still needs an ~/.emacs, so I'm unsure it's a great improvement over a single ~/.emacs.d. That said, you could try to start emacs with the --load or --directory argument. -- Alad (talk) 09:15, 1 September 2015 (UTC)


I've just revised the VCS management of my config files and had to put configs of practically all graphical programs to .gitignore, because they all abuse the $XDG_CONFIG_HOME path for the purpose of persistent cache, which is $XDG_CACHE_HOME. A typical config file of a Qt programs looks like this, notice especially the recentFileList, geometry and windowState keys -- IMHO this is exactly the stuff that belongs to $XDG_CACHE_HOME or $XDG_DATA_HOME. The Qt programs are notorious, I suspect the toolkit itself is responsible. But there is more: inkscape puts there extension-errors.log, syncthing even the entire database. What shall we do about this? There are not many graphical programs in the tables on this page, but inkscape is listed under "Supported", which is not entirely true... -- Lahwaacz (talk) 22:12, 21 August 2015 (UTC)

The article uses "workarounds [that] will be limited to anything not involving patching the source, executing code stored in environment variables or compile-time options." as an arbiter for the "Partial" category, and anything more complicated than that for "Hardcoded". I.e., categorization is based on what's needed to moving dotfiles from $HOME to some, hopefully correct, XDG directory or directories.
One way to supplement this would be the Notes column in the Supported category (which is now mostly empty anyway), to expand on programs which don't follow the intent of the XDG directories or which just lazily stack things together. -- Alad (talk) 09:08, 1 September 2015 (UTC)
This is why adding * to GIT_DIR/info/exclude is so great. I have no idea why people who are familiar with git don't do this by default. This allows you to only track files you explicitly want to track with impunity. But yes, there's plenty of programs which don't follow the spec to the letter and that's mostly fine; it's fine because at least the root of their directory is now under user control. Using git properly makes this a non-issue and I'd rather projects at least support some of XDG than be forever debating what "cache" vs "data" means... Earnest (talk) 15:31, 12 September 2015 (UTC)

Should command-line history be data or cache?

Should they be placed in XDG_DATA_HOME, or XDG_CACHE_HOME? --Franklin Yu (talk) 20:07, 16 May 2017 (UTC)

Cache is data than can be deleted at any time without losing anything important, as it can be regenerated by the application (e.g. by re-downloading something or otherwise). Data in XDG_DATA_HOME on the other hand has an impact on what the user can do, and the user would mind about losing it. Of course it may depend on the application in question where you draw the line of what's "important", but when deleting command line history, (1) the user loses possibilities (reusing a command) and information/knowlege ("what was that command again?"), and (2) the data cannot be regenerated by the application, so I would clearly put it in XDG_DATA_HOME. —Ayekat (talk) 22:30, 16 May 2017 (UTC)

nvidia uses XDG_CACHE_HOME, how to test CUDA?

Using nvidia 390.25 and just noticed that it now stores its cache in $XDG_CACHE_HOME/.nv rather than ~/.nv and edited the page accordingly. I don't know if CUDA was also changed and don't know how to check. If someone else knows, please tell me or try it yourself and update the page if needed. I already checked nvidia-settings, it is not yet changed.

Cyant (talk) 11:55, 25 February 2018 (UTC)

Won't fix section

I don't particularly like having this section or even mentioning developers marked something as "won't fix". You should check previous discussion anyway when using this article as a guide and those discussions may be old and may need revisiting once in a while.

This section being separate just encourages ignoring these applications (and not proposing patches) when opinions of developers may change in the future if to be presented with compelling argument and/or patch.

Supported, Partial and Hardcoded criteria is based on whether feature is supported by software in question, not what its developers think of implementing it. I think label "Won't fix" does not do full justice to complexity of the issue and just may be incorrect assessment of "I do not want to implement this myself right now", "there is no good enough patch", "I have no clue why this is needed" and many other arguments that should be tackled with reason and confidence.

Opinions of developers should not matter. You fork, you patch, you submit your changes. If they are rejected - no biggie, you just have a nice patchset for yourself you can share with others and here.

If you have not made a compelling enough argument, your argument gets "won't fix". Why would anyone fix your argument for you?

Another reason to have "Won't fix" section is to prevent poor behavior on these projects' trackers but I would argue that's entirely different topic that probably should warrant "Submitting proposal to upstream projects" section in this article specific to this issue so people are well armed and communicate it better and avoid common pitfalls or degrade the discussion, possibly even have relevant issue template or FAQ.

-- Svito (talk) 15:06, 22 September 2018 (UTC)

Fine, I merged the Won't fix section back into the Hardcoded table. I don't think this page links a single patch. The won't indicator can be seen as 1) probably won't accept patches or 2) needs persuasion (if you are that ambitious). --Larivact (talk) 20:42, 22 September 2018 (UTC)

Suggestions for GnuPG

Current suggestion for GnuPG is

$ gpg2 --homedir "$XDG_CONFIG_HOME"/gnupg

However, GnuPG places more than configuration files in $GNUPGHOME. For example, in my machine I have following files

  • pubring.kbx
  • trustdb.gpg

Both are binary files. According to the name they are the public key ring and some database. I don't think they belong to $XDG_CONFIG_HOME. Maybe we should specify their path manually, to re-direct them to somewhere in $XDG_DATA_HOME? --Franklin Yu (talk) 21:13, 14 November 2018 (UTC)