Differences between revisions 7 and 8
Revision 7 as of 2013-08-20 18:08:23
Size: 3456
Editor: ThomasKoch
Comment:
Revision 8 as of 2013-10-16 10:00:14
Size: 3754
Editor: ThomasKoch
Comment:
Deletions are marked like this. Additions are marked like this.
Line 12: Line 12:
== Tools == <<Anchor(libraries)>>
== Tools and libraries ==
Line 14: Line 15:
 * [[DebianPkg:src:libxdg-basedir]]
 * [[DebianPkg:src:haskell-xdg-basedir]]
 * [[DebianPkg:src:pyxdg]]
 * Haskell: [[DebianPkg:src:haskell-xdg-basedir|haskell-xdg-basedir]]
 * Python: [[DebianPkg:src:pyxdg|python-xdg/python3-xdg]]
 * C++/QT: [[DebianPackage:libqtxdg0-dev|libqtxdg]]
 * C: [[DebianPkg:src:libxdg-basedir|libxdg-basedir]]
 * C/Gnome: [[https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-get-user-cache-dir|via glib]])

The XDG Base Directory Specification (XDGBDS) defines four directories in a users $HOME dir that should be used for so called DotFiles.

These directories (with their default locations) are:

  • $XDG_DATA_HOME ($HOME/.local/share): data files
  • $XDG_CONFIG_HOME ($HOME/.config): configuration files
  • $XDG_CACHE_HOME ($HOME/.cache): non-essential data files
  • $XDG_RUNTIME_DIR (no default?): non-essential runtime files, other file objects (such as sockets, named pipes, ...)

Please refer to the specification for additional directory definitions and further details.

Tools and libraries

Status of Packages

TODO: Which packages do not conform to the XDGBDS and has a bug been filled upstream?

* mplayer: upstream bug * xmonad: upstream bug

e.g.: ZSH, gimp, ssh, gnupg, mplayer, dbus, libpurple/pidgin,

Proposal: STATE directory

This is a recurring request/complaint (see this or this) on the xdg-freedesktop mailing list to introduce another directory for state information that does not belong in any of the existing categories (see also home-dir.proposal. Examples for this information are:

  • history files of shells, repls, anything that uses libreadline
  • logfiles
  • state of application windows on exit
  • recently opened file
  • last time application was run

The above example information is not essential data. However it should still persist on reboots of the system unlike cache data that a user might consider putting in a TMPFS. On the other hand the data is rather volatile and does not make sense to be checked into a VCS. The files are also not the data files that an application works on.

Some questions that might help to distinguish between the different classes:

DATA

CONFIG

STATE

CACHE

RUNTIME

sync across machines?

yes?

yes

no

no

no

manage in VCS (Git/SVN)?

no

yes

no

no

no

should be backed up?

yes

yes

yes

no

no

can live in tmpfs?

no

no

no

yes

yes?

contains much data?

yes

no

no

yes

no