volatile config data and XDG Base Directory spec

[Ryan Lortie]

hi,

On Wed, Feb 19, 2014, at 7:40, Simon McVittie wrote:
> I agree that storing state in ~/.config is a bug, but I think that's a
> misuse of existing categories rather than a need for a new category -
> why wouldn't ~/.local/share be OK? - and I don't think adding new
> categories is going to reduce developer confusion/misuse between
> categories.

Lennart and I had a discussion about this at GUADEC and we came to the
opposite conclusion.

I'll write down here what I got out of that discussion, but I think we
mostly agree.

The message that we want to send is "if in doubt, use ~/.config/".

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.  I
find this symmetry to be very nice -- and particularly it means that
XDG_DATA_HOME and XDG_DATA_DIRS would then mean the same thing, and I
would be comfortable modifying the spec to be much more strongly-worded
with regards to how you should always use both for the same purpose
(when reading).

I think ~/.config/ is a bit of a weird name for "toss all of the data
here", but so is ~/Library/.  ~/.config/ is established.  You also have
things like dconf that are storing data here that is definitely
configuration, but also kinda not the sort of "config" you'd expect in
/etc -- ie: you couldn't go in there and edit it with a text editor. 
Another example of something that feel a little more state-like but not
exactly config: ~/.config/monitors.xml.

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

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

In general, it is expected that you do not place such a subdirectory in
~/.local/share/ -- rather you would install into one of the "well know"
directories for fonts, etc.  An exception is if your program has
something like plugins and you have a system directory for that as well
-- then you could name this in the D-Bus style.

The main thrust behind this conclusion is that we've had a lot of people
from a wide range of areas (everyone from game developers to Firefox)
telling us that the current split of "config" vs. "data" is very
difficult for them to support and not something that they have on other
platforms.  I agree that adding another directory would not help here. 
Blessing "just use ~/.config" as the official way forward would help
these people a lot.

A couple of caveats:

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, and thinking about this, would we
honestly expect to have this in ~/.config/?  I think that this folder is
truly unique, and putting it in the location that it has now was
probably not a great choice... I think we could just leave it there and
acknowledge that it's weird.

Cheers