volatile config data and XDG Base Directory spec
simon.mcvittie at collabora.co.uk
Wed Feb 19 07:29:57 PST 2014
On 19/02/14 13:03, Ryan Lortie wrote:
> Specifically, we feel that things should only be "installed" into
> ~/.local/share/. Things like fonts, plugins, desktop files, dbus
> service files, icons, themes, etc. -- essentially things that you would
> also find in /usr/share if the sysadmin had installed them instead.
This is a significant policy change. At the moment, ~/.local/share has a
dual role as the home-directory equivalent of both /usr/share and
/var/lib, and is considered to be the right place for user data in
non-document-oriented applications (anything that insta-saves
automatically and doesn't use a Save As dialog), for instance:
* Rhythmbox playlists
* Tomboy notes
* Telepathy (Mission Control) accounts
* Telepathy IM logs
* the Tracker database
* the Evolution address book, calendar etc.
(all of those are non-hypothetical: they exist in my ~/.local/share)
A rule of thumb from
> But how do you know what goes in what folder ?
> There’s a little trick : just imagine that it was deleted. What would
> you think as a user ?
> If you would cry, running frenetically to your backup, it means that
> it belongs to XDG_DATA_HOME.
> If you would think “Damn, I will have to reconfigure all”, it belongs
> to $XDG_CONFIG_HOME. [...]
> If you would just think “It’s bloody slow those days” then it is
> obviously part of XDG_CACHE_HOME.
> In general, I'd like to tell people that "If your program wants to
> install things like plugins|fonts|etc, put them in XDG_DATA_HOME. All
> other state goes in XDG_CONFIG_HOME. This includes things like
> databases and game state and save files."
People who put their ~/.config in a VCS are going to hate that change,
and so are people who use deletion of ~/.config as a "factory reset"
(but don't want to lose, e.g., their Tomboy notes).
If the authors of a particular application don't want to distinguish
between configuration and data, that's a feature-request bug that might
reasonably be WONTFIX, but I think XDG_DATA_HOME is a better fallback
for such applications than XDG_CONFIG_HOME.
> We'd also like to tell people that applications putting data in
> ~/.config/ are expected to use the D-Bus style naming scheme to select a
> directory for themselves. We would enforce this for sandboxed
> applications. OS components would be exempted from this restriction
> (both as a matter of policy and enforcement).
I assume service/daemon/behind-the-scenes things like dconf, Telepathy,
GNOME Online Accounts, etc. count as OS components for these purposes?
> 1) I mention "plugins" above while talking about "share". This should
> set off alarm bells -- maybe we could also reopen the ~/.lib/x86/ vs.
> ~/.lib/amd64/ etc. debate (but we should keep that a separate discussion
> from this, imho.).
> 2) ~/.local/share/Trash/ is weird
It's weird in a "~/.local/share is the user's /usr/share" world-view. In
a world-view that says "~/.local/share is a hybrid of /usr/share and
/var/lib" it's perfectly normal: if Trash was a system service, it would
be correct for trashed files to go in /var/lib/Trash or something.
More information about the xdg