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

[Lennart Poettering]

On Fri, 04.07.14 13:21, Simon McVittie (simon.mcvittie at 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