[systemd-devel] file-hierarchy. user persistent data dir.

[Simon McVittie]

On 04/07/14 11:33, Lennart Poettering wrote:
> ~/.config: state and configuration, the counterpart for both /etc/ *and*
>            /var/lib/ in the home directory
> 
> ~/.local: static vendor resources of additional packages installed into
>           the home directory. Should be considered read-only except when
>           new packages are installed or removed from the home
>           directory. The counterpart of /usr/ in the home directory.

This is not, in practice, what happens: I certainly have a lot of state
(/var/lib-like) in my ~/.local/share.

It isn't clear to me that there's consensus that all applications that
do this have always been wrong, and so is Lionel Dricot's somewhat
widely-cited guide
<http://ploum.net/207-modify-your-application-to-use-xdg-folders/>. If
I'm the only one who still thinks like that, fine, change the policy;
but the number of applications putting state in my ~/.local/share seems
like anecdotal evidence that I'm not the only one with that mental model :-)

Also, on Windows, GLib's g_get_user_data_dir() returns
CSIDL_LOCAL_APPDATA, which is primarily a state directory (the same
thing returned by g_get_user_config_dir(), in fact). Is that wrong?

The major use-cases I've seen for splitting configuration vs. state are:

* keep your config in a VCS, don't keep your state/data in a VCS
* reset config to "factory defaults" without losing state/data

If you don't consider those use-cases to be interesting or useful, fine
(I consider the second one to be something I'd never want to do), but
please do consider them before breaking them.

My proposal, which I think matches how Ted Gould said Ubuntu's
sandboxing works:

* An application with ID foo[1] may write to
  ${XDG_CONFIG_HOME:~/.config}/foo during normal operation;
  this location
  is intended for [?]

  (my point of view: configuration)
  (Lennart's point of view: configuration, state, and miscellaneous
  user data)

* foo may write to ${XDG_DATA_HOME:~/.local/share}/foo during normal
  operation; this location is intended for [?]

  (my point of view: state, miscellaneous user data, and
  read-only resources)
  (Lennart's point of view: read-only resources)

* foo may write to ${XDG_CACHE_HOME:~/.cache}/foo during normal
  operation, but must assume that files in there may be deleted

* foo must not assume that it can write to
  ${XDG_DATA_HOME:~/.local/share}/bar (for bar != foo) during normal
  operation, only when it is installed or uninstalled (e.g. an app
  installer can write to ~/.local/share/applications/foo.desktop
  but foo itself cannot)

I think that keeps the ability to sandbox, while preserving the layout
that various apps have come to rely on, and not making life worse for
people who do distinguish between config and other data?

Regards,
    S

[1] where foo is from some namespace outside the scope of basedir:
reversed domain name, or GUID, or name in /usr/bin, or distro package
name, or whatever. The exact definition is not important here.