|
Size: 3456
Comment:
|
Size: 3754
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
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 |
