Bug#752075: daemontools-run: Add systemd support

[Gerrit Pape]

Hi Michael,

On Fri, Jul 18, 2014 at 08:06:11PM +0200, Michael Stapelberg wrote:
> Gerrit Pape <pape at dbnbgs.smarden.org> writes:
> > I'm really not keen to add a dependency to daemontools-run, esp. not to
> > the runit package, just for (un)installing and starting/stopping a
> > service.
> I presume you mean init-system-helpers as the dependency you don???t want
> to add.

Any dependency:
$ apt-cache show runit |grep ^Depends
$ apt-cache show daemontools-run |grep ^Depends
Depends: daemontools (>> 1:0.76)
$ apt-cache show daemontools |grep ^Depends
Depends: libc6 (>= 2.7-1)
$ 

> > Why isn't it as simple as installing the unit, and then?:
> >
> >  systemd not installed || start service
> It is as simple as that. deb-systemd-invoke supports policy-rc.d,
> though, which your intended example (AIUI) does not. You???d make some
> users really unhappy if you break policy-rc.d with your package.

I don't think so.  The daemontools-run and runit packages don't include
init scripts.  policy-rc.d never had an effect on them, so nothing will
break.

> >  systemd not installed || have service started by default
> When systemd is not installed, where does the logic for having the
> service started by default come from? While the actually relevant part
> of that is as simple as creating a symlink, there are some things make
> this entire process more complicated. Some of them come from the fact

I hope this "as simple as creating a symlink" works out.

> that the enabled-state needs to be synchronized across init systems,
> i.e. what you do in systemd should also work for the
> sysvinit-fallback.

This is not necessary for the packages in question.  They have an inittab
entry since many years
 SV:123456:respawn:/usr/sbin/runsvdir-start
The whole purpose of the packages is to provide this service, no
"enabled-state" is needed.

$ apt-cache show runit |grep ^Description-en
Description-en: system-wide service supervision
$ apt-cache show daemontools-run |grep ^Description-en
Description-en: daemontools service supervision
$

> Further, consider this (from the manpage of deb-systemd-helper):
> 
>   The "enable" action will only be performed once (when first installing
>   the package). On the first "enable", an state file is created which
>   will be deleted upon "purge".
> 
> ???which enables administrators to disable units and not have them
> magically re-enabled on the next package upgrade.

See above, I don't think this applies.

> Also, the dh-systemd/deb-systemd-helper combination properly handles
> mask-after-remove (i.e. remove but not purge).

Anything wrong in this regard with my current implementation?

> In general, it???s hugely beneficial to Debian if packages use the same
> helpers/debhelper addons to build their maintainer scripts. Bugfixes and
> other improvements that we put into i-s-h will propagate to all packages
> without coordinating huge updates/fixes. You don???t need to think about
> all the intricacies of correctly handling unit files (in Debian!)
> because we already did it.

We're different individuals in Debian and have different opinions.  To
me it's beneficial to Debian if there still exist packages not using
debhelper, doing things differently than others, even than the masses,
following KISS.  I want to think about and understand how the inittab
entry
 SV:123456:respawn:/usr/sbin/runsvdir-start
translates most easily into a systemd service, now that I learned that
this is necessary because systemd doesn't provide backward compatibility
for such services.

> Let me also point out that _every_ system already has i-s-h installed
> these days, so there really is no cost in adding this dependency.

That's not true.  Just a few of my systems have this package pulled in,
all of them have runit installed.

Regards, Gerrit.