Re: [systemd-devel] ~/.local/share/systemd/user
On Sat, 07.06.14 13:07, Tanu Kaskinen (tanu.kaski...@linux.intel.com) 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. I didn't always see it this way, but I do agree with you now. So, would a patch that removes the symlinking be accepted? Yes, please! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ~/.local/share/systemd/user
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
[systemd-devel] ~/.local/share/systemd/user
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. 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? -- Tanu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ~/.local/share/systemd/user
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. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpvxu0pe6Koi.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ~/.local/share/systemd/user
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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ~/.local/share/systemd/user
On Sat, Jun 07, 2014 at 04:03:33PM +0300, Tanu Kaskinen wrote: 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. Both directories are supported, i.e. you can drop a unit using either path, and it will be used by systemd. A symlink is used to avoid having two directories. Your usecase hasn't been brought up before, so there was little reason to have two. 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. So far nobody raised this subject, but systemd --user is still relatively unused, so maybe that's why. Lennart, do you have any master plan here? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
