Re: thoughts on rudimentary dependency handling

From: Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups_at_NTLWorld.com>
Date: Mon, 19 Jan 2015 23:00:26 +0000

John Albietz:
> I wonder if this will help address a common situation for me where I
> install a package and realize that at the end of the installation the
> daemon is started using upstart or sysv.
>
> At that point, to 'supervise' the app, I first have to stop the current
> daemon and then start it up using runit or another process manager.

On Debian, for one, they aren't started using upstart or sysv (whatever
that is). Maintainer scripts enable them with update-rc.d and start
them with invoke-rc.d. You are expected to have update-rc.d and
invoke-rc.d tools that are appropriate to your init system, as well as
the respective control files of course.

openrc comes with update-rc.d and invoke-rc.d that understand openrc
scripts. The sysv-rc package comes with update-rc.d and invoke-rc.d
that understand systemd units, upstart jobs, and System 5 rc.d scripts.
  Ironically, the systemd and upstart packages do not come with their
own update-rc.d and invoke-rc.d commands, relying instead upon the
sysv-rc package to supply them.

This is all a bit shakey and rickety, though. One well-known fly in the
ointment is that what may be a single init.d script for System 5 rc may
be multiple service and socket units for systemd, and stopping a
socket-activated service for package upgrade might not do the right
thing as the socket activation might activate the service unit mid-upgrade.

Last year, I gave Debian Developer Russ Allbery a patch for an improved
version of the Debian Policy Manual that sets this out more clearly than
the current one. You might want to get it off him. The sections (of the
patched document) that you are interested in are 9.3.1.2, 9.3.6,
9.3.6.1, 9.3.6.2, and 9.3.6.3.
Received on Mon Jan 19 2015 - 23:00:26 UTC