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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
