Discussion:
gnupg: systemd enable in post_install
(too old to reply)
Damjan Georgievski via arch-general
2017-06-09 10:13:32 UTC
Permalink
Raw Message
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=packages/gnupg#n21

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.
--
damjan
Jan Alexander Steffens via arch-general
2017-06-09 11:13:02 UTC
Permalink
Raw Message
On Fri, Jun 9, 2017 at 12:13 PM Damjan Georgievski via arch-general <
Post by Damjan Georgievski via arch-general
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=packages/gnupg#n21
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.
Post by Damjan Georgievski via arch-general
dbus does that for ex.
The DBus `make install` sets it up that way; it wasn't a downstream
decision.
Damjan Georgievski via arch-general
2017-06-09 11:17:35 UTC
Permalink
Raw Message
Post by Jan Alexander Steffens via arch-general
Post by Damjan Georgievski via arch-general
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=packages/gnupg#n21
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.
--
damjan
Georg
2017-06-09 12:24:35 UTC
Permalink
Raw Message
Post by Jan Alexander Steffens via arch-general
Post by Damjan Georgievski via arch-general
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=packages/gnupg#n21
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.
Post by Damjan Georgievski via arch-general
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
Leonid Isaev via arch-general
2017-06-10 04:39:04 UTC
Permalink
Raw Message
Post by Georg
Post by Jan Alexander Steffens via arch-general
Post by Damjan Georgievski via arch-general
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=packages/gnupg#n21
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.
Post by Damjan Georgievski via arch-general
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,
--
Leonid Isaev
Loading...