volatile config data and XDG Base Directory spec

[Simon McVittie]

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
<http://ploum.net/207-modify-your-application-to-use-xdg-folders/>:
> 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.

Ryan wrote:
> 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.).

~/.lib/i386-linux-gnu :-P

> 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.

    S