[systemd-devel] ~/.local/share/systemd/user

[Tanu Kaskinen]

On Sat, 2014-06-07 at 07:42 -0500, William Giokas wrote:
> On Sat, Jun 07, 2014 at 01:07:08PM +0300, Tanu Kaskinen wrote:
> > Hi,
> > 
> > Currently, systemd symlinks ~/.local/share/systemd/user to
> > ~/.config/systemd/user. I'd prefer to not have that symlink. I'd want the
> > two locations have different semantics, analogous to the separation between
> > /usr/lib/systemd/user and /etc/systemd/user, i.e. service upstreams should
> > install units to ~/.local/share/systemd/user and users should customize in
> > ~/.config/systemd/user.
> 
> For me this is a directory, not a symlink.

By "this", do you mean ~/.local/share/systemd/user? I don't know how
that got created. The current systemd code creates the symlink, unless
~/.local/share/systemd/user already exists (so on your machine the
symlink won't be created, unless you remove the directory first).

> > I suppose there are very few service upstreams that install their software
> > to the user home directory, but I happen to be writing such software myself.
> > My project is just a toy, though, but I think the general approach of
> > installing a user service to the user home directory makes sense, as it
> > avoids the need to have root access.
> > 
> > So, would a patch that removes the symlinking be accepted?
> 
> So for user services there are 3 directories that packages can be,
> checked in order:
> 
>   ~/.config/systemd/user
>   /etc/systemd/user/
>   /usr/lib/systemd/user
> 
> I don't see a reason to have a fourth one 'for packages' in a users home
> directory.

The same reasons apply that apply for the /etc and /usr/lib separation:
it makes sense to keep upstream units separate from local stuff.

If you think that it doesn't make sense to support the rare kind of
services that are meant to be installed in the home directory, then ok,
I can live with that. But then I wonder why systemd bothers looking at
all at ~/.local/share/systemd/user as it currently does.

-- 
Tanu