On Sat, 07.06.14 07:42, William Giokas (1007...@gmail.com) 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. > > > 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.
While that is what I thought too when I implemented the code for the symlink, I come to disagree now. ~/.config is where user configuration shall be placed. It's editable by the user. It corresponds with /etc on the system level ~/.local OTOH is where vendor data for additional packages installed by the user can be placed, and where they should be picked up. It corresponds with /usr on the system level. ~/.local should be considered mostly read-only, unless you actually install or remove stuff. ~/.config is more frequently written to, whenever the user actually wants to change configuration. In a way, ~/.local is supposed to be the place where users can install things into if they use "./configure --prefix=$HOME/.local" (which doesn't really work too nicely for many other reasons, but you get the idea). Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
