On Fri, 04.07.14 13:21, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote:
> > 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. Yes, of course. I am fully aware of that and I already mentioned that even. > 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. Actually, I so far kept my home directory in a VCS too. However, I am also aware that the destinction between state and configuration is very vague and nothing I want to dump on people's heads for desktop apps (that we do this for system stuff is difficult enough). The distinction is already completeld thwarted anyway by the fact that gconf/dconf-like systems are making this scheme impossible anyway, as they already are the single location for both configuration and state (also, you cannot check them into VCS anyway). So yupp, I think neither the VCS issue nor the destinction between configuration and state are really reasons strong enough to keep this. I think ~/.config should be little more than a file-system counterpart of dconf, and this means, VCS-compatibility, and the distinction between state and configuration are not at the center. The thing with all of this is that we should make a spec so simple that people can make sense of (for example, Mozilla made clear they find the spec so stupid they won't support it, more or less). And yeah, if we can tell people that there's just one directory they really have to care about, which is ~/.config, then things get relatively easy to tell people about. I am also not particularly concerned that many apps don't follow these guidelines right now. This is fully OK, after all $HOME is writable for everybody, currently. However, as part of bringing sandboxing to Linux we can clean up this mess, and can and have to enforce much stricter rules here. The sandboxing will be something that will break a number of different areas where people made assumptions, no doubt, this is just going to be one of them. Summary: current apps can do whatever they want in $HOME, including ignoring the spec entirely. Sandboxed apps won't. But if you have want to make your app work in a sandbox, then you have to make a couple of changes anyway, this once is just one of them. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel