* orphan-sysvinit-scripts

** Introduction

This is ~orphan-sysvinit-scripts~, a home for init scripts that have
been discarded by their package maintainers. It's not as nice as
having the init script in its related package, but it provides most of
what our users need.

** Approach

We register ~dpkg~ triggers for the ~systemd~ service file for the
packages whose init scripts we manage. We then use ~ucf~ to manage
them like conffiles. The triggers are generated at package build time
from the contents of ~lib/mapping~.

In practice, whenever we are triggered, we check every init script we
know about; this is lazy, but the process is quick, so the simplicity
(and thus reduction in bug count) is probably a good trade-off.

** Adding a new orphan

First, it may be worth asking the maintainer to reconsider; if they
just are under the impression no-one needs the init script any more,
you might be able to persuade them to reconsider.

Otherwise, you need to do the following:
- Get hold of a copy of the most recent init script - put it in ~scripts/~
- Establish what the copyright status of it is, and update
  ~debian/copyright~
- Put the md5sum of the new script into ~scripts/scriptname.md5sum~ along
  with the version of orphan-sysvinit-scripts it's first appearing in
- Check if the package wants something other than "defaults" as an
  argument to ~update-rc.d~
- Add a line to ~lib/mapping~ with the systemd unit name and sysvinit
  file name (and, iff necessary, update-rc.d argument) in

** Bugs / Limitations

Many of these are inevitable downsides of having init scripts in this
package rather than in their related package.

- We try to avoid purging init scripts that the user is responsible
  for (i.e. that we never managed). This means we will sometimes leave
  droppings.
- We don't try to remove init scripts if the corresponding package is
  removed. This seems right, as otherwise removing a package would
  have the effect of purging its init script (which is a config
  file). We could in theory try and work out if the relevant package
  has been purged, but that would be much more complex.
- In any case, it's not ideal that purging follows this package, not
  the relevant daemon package.
- Handoff of responsibility for the conffile may not be seamless, so
  some users may be prompted about conffiles where ideally they would
  not be.
- If the CLI syntax for a daemon changes between versions, it's not
  possible for this package to arrange for the correct init script to
  always exist
- We don't know about actions that might need taking when the related
  package is upgraded (e.g. reload/restart &c)
- Over-zealous conffile removal from the related package might remove
  the init script we have installed (since the one here will typically
  be the same as the one the related package no longer wants)
- Downgrading from 0.14 (which has the ~rsyslog-rotate~ diversion) or
  later to an earlier version (without the diversion) will leave the
  diversion in place and no ~/usr/lib/rsyslog/rsyslog-rotate~ (this is
  a consequence of the fact that maintainer scripts are all run before
  files in the previous version of a package but not in the current
  one are removed). You can fix by hand thus
  ~dpkg-divert --remove --rename --divert /usr/lib/rsyslog/rsyslog-rotate.real /usr/lib/rsyslog/rsyslog-rotate~

