what's the rationale to enable the gnupg sockets in post_install of the package? https://git.archlinux.org/svntogit/packages.git/tree/trunk/install?h=package...
I don't disagree that the sockets maybe should be enabled (I have them enabled for me), it's just a strange way to enable them in post_install, and linking them in /etc/
Why doesn't the PKGBUILD make the symlinks in /usr/lib/systemd/user/sockets.target.wants/ ?
dbus does that for ex.
On Fri, Jun 9, 2017 at 12:13 PM Damjan Georgievski via arch-general < arch-general@archlinux.org> wrote:
what's the rationale to enable the gnupg sockets in post_install of the package?
https://git.archlinux.org/svntogit/packages.git/tree/trunk/install?h=package...
I don't disagree that the sockets maybe should be enabled (I have them enabled for me), it's just a strange way to enable them in post_install, and linking them in /etc/
Why doesn't the PKGBUILD make the symlinks in /usr/lib/systemd/user/sockets.target.wants/ ?
I did that in the pulseaudio package at first and people complained that they couldn't "disable" the pulseaudio socket and "mask" also prevented a manual start.
Hence I moved pulseaudio from static symlinks to enable/disable post_install.
GnuPG follows this.
dbus does that for ex.
The DBus `make install` sets it up that way; it wasn't a downstream decision.
what's the rationale to enable the gnupg sockets in post_install of the package?
https://git.archlinux.org/svntogit/packages.git/tree/trunk/install?h=package...
I don't disagree that the sockets maybe should be enabled (I have them enabled for me), it's just a strange way to enable them in post_install, and linking them in /etc/
Why doesn't the PKGBUILD make the symlinks in /usr/lib/systemd/user/sockets.target.wants/ ?
I did that in the pulseaudio package at first and people complained that they couldn't "disable" the pulseaudio socket and "mask" also prevented a manual start.
got it. makes sense
though users will need root privileges to disable it then, but I guess for Arch that doesn't matter.
what's the rationale to enable the gnupg sockets in post_install of the package?
https://git.archlinux.org/svntogit/packages.git/tree/trunk/install?h=package...
I don't disagree that the sockets maybe should be enabled (I have them enabled for me), it's just a strange way to enable them in post_install, and linking them in /etc/
Why doesn't the PKGBUILD make the symlinks in /usr/lib/systemd/user/sockets.target.wants/ ?
I did that in the pulseaudio package at first and people complained that they couldn't "disable" the pulseaudio socket and "mask" also prevented a manual start.
Hence I moved pulseaudio from static symlinks to enable/disable post_install.
GnuPG follows this.
dbus does that for ex.
The DBus `make install` sets it up that way; it wasn't a downstream decision.
Packages should never enable or start any services. The same holds for sockets IMHO. From my point of view the appropriate solution would be a message in post_install stating the necessity of enabling the socket/service.
georg
On Fri, Jun 09, 2017 at 02:24:35PM +0200, Georg wrote:
what's the rationale to enable the gnupg sockets in post_install of the package?
https://git.archlinux.org/svntogit/packages.git/tree/trunk/install?h=package...
I don't disagree that the sockets maybe should be enabled (I have them enabled for me), it's just a strange way to enable them in post_install, and linking them in /etc/
Why doesn't the PKGBUILD make the symlinks in /usr/lib/systemd/user/sockets.target.wants/ ?
I did that in the pulseaudio package at first and people complained that they couldn't "disable" the pulseaudio socket and "mask" also prevented a manual start.
Hence I moved pulseaudio from static symlinks to enable/disable post_install.
GnuPG follows this.
dbus does that for ex.
The DBus `make install` sets it up that way; it wasn't a downstream decision.
Packages should never enable or start any services. The same holds for sockets IMHO. From my point of view the appropriate solution would be a message in post_install stating the necessity of enabling the socket/service.
There is no such necessity, fwiw. If gpg-agent or dirmngr need to be started, there is .bash_login and such (and dirmng is started by gpg automatically anyways). This dependence on systemd is an abomination because it breaks in so many unpredictable ways. For example, with systemd 233, epiphany freezes when started inside a container and systemd "is looping too fast" (and no, I'm not reporting it upstream), but works if I manually kill systemd --user instance.
If you are not using Xorg, "pkill -9 systemd" in .bash_profile saves lots of hair-pulling :)
Cheers,
arch-general@lists.archlinux.org