gnupg: systemd enable in post_install

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

gnupg: systemd enable in post_install

arch general mailing list-2
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
Reply | Threaded
Open this post in threaded view
|

Re: gnupg: systemd enable in post_install

arch general mailing list-2
On Fri, Jun 9, 2017 at 12:13 PM Damjan Georgievski via arch-general <
[hidden email]> 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=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.


> dbus does that for ex.
>

The DBus `make install` sets it up that way; it wasn't a downstream
decision.
Reply | Threaded
Open this post in threaded view
|

Re: gnupg: systemd enable in post_install

arch general mailing list-2
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: gnupg: systemd enable in post_install

G. Schlisio-2
In reply to this post by arch general mailing list-2
>> 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.
>
>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: gnupg: systemd enable in post_install

arch general mailing list-2
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=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.
> >
> >
> > > 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