1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71
|
* 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~
|