|
Size: 3754
Comment:
|
Size: 3841
Comment: Add header from DefaultTemplate; formatting.
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| #language en ~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: none-~ ---- |
|
| Line 25: | Line 28: |
| * mplayer: [[http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1857|upstream bug]] * xmonad: [[http://code.google.com/p/xmonad/issues/detail?id=484|upstream bug]] |
* mplayer: [[http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1857|upstream bug]] * xmonad: [[http://code.google.com/p/xmonad/issues/detail?id=484|upstream bug]] |
Translation(s): none
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
Haskell: haskell-xdg-basedir
Python: python-xdg/python3-xdg
C++/QT: libqtxdg
C/Gnome: via glib)
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,
Links
Modify your application to use XDG folders - Blog post from Lionel Dricot
Fedora initiative to make packages conform to XDGBDS
Gnome Goal to conform to XDGBDS
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 |