[PATCH 3/4] update-rc.d: add runlevel link migration interface

[Michael Biebl]

Kel Modderman wrote:
> When run with the from ... to ... options, update-rc.d can migrate the runlevel
> links for a script from old defaults to new defaults while preserving any
> local modifications.
> 
> It is intended that this be used only in maintainer scripts of packages wishing
> to change the runlevel link configuration for a service script while preserving
> locally modified link configurations.
> 
> Real world example
> ==================
> Package `hotkey-setup' used default dh_installinit settings up until package
> version 0.1-17.2. In all of those package versions, the dh_installinit
> autogenerated section of hotkey-setup.postinst contained the update-rc.d
> command: "update-rc.d hotkey-setup defaults"
> 
> In hotkey-setup package version 0.1-17.2, the postinst maintainer script looks
> like:
> ===
> # Remove symlinks to script to have them reinserted by debhelper
> # without the shutdown and reboot links; this init script does not
> # need them.
> if dpkg --compare-versions "$2" lt "0.1-17.2"; then
> 	update-rc.d -f hotkey-setup remove
> fi
> 
> #DEBHELPER#
> ===
> 
> Installation of this version of hotkey-setup would force the purge of existing
> runlevel links for /etc/init.d/hotkey-setup, so that the new dh_installinit
> autogenerated update-rc.d command could take effect. This practise does not
> preserve administrator modified runlevel configuration and is therefore prone
> to error, policy violation bugs and end user complaint.
> 
> Using the "from ... to ..." feature, the same result could have been achieved
> with a postinst snippet similar to:
> ===
> # Drop shutdown link from runlevels 0 and 6, this package does not require them
> if dpkg --compare-versions "$2" lt "0.1-17.2"; then
> 	update-rc.d hotkey-setup from defaults to start 20 2 3 4 5 . stop 20 1 .
> fi
> 
> #DEBHELPER#

Hi Kel,

there is one major issue that I don't like about this approach: It's not
fool proof and requires quite a bit of work to get right for the maintainer.

I assume, you chose the from .. to scheme, as you have detect local
modifications.

I'd propose a different approach: We use a state file (e.g.
/var/lib/sysvinit) to detect local modifications.
Real world example:

version 0.1-1
# update-rc.d foo defaults
Installs start/stop symlinks and adds the following line to
/var/lib/sysvinit:
foo defaults

Maintainer decides to drop the stop symlinks for 0,6 in 0.1-2
# update-rc.d foo start 20 2 3 4 5 . stop 20 1 .
update-rc.d will compare the recorded state in /var/lib/sysvinit and
update the priorities accordingly (or leave them untouched). Then write
the new information to /var/lib/sysvinit:
foo 20 2 3 4 5 . stop 20 1 .

The maintainer doesn't have to care for version numbers and maintainer
scripts. He simply uses the new priorities in his call to dh_installinit.
This would be much less error prone imho.
Given, how often I've seen maintainers change the location of conffiles
without adding the necessary logic to the maintainer scripts to (re)move
the existing conffiles, I'd very much favour an approach which is as
fool proof and easy to use as possible.


A state file would have another advantage, something that has bothered
me for a while. Say you have removed all symlinks via
update-rc.d -f foo remove

Now you want to reinsert them with the correct priorities. That means
you have to checkout the packages' postinst script to get the correct
parameters.

If we had a state file, update-rc.d could look there and use that when
called with "defaults" (as this would change the behaviour of
"defaults", we could also invent a new keyword like "auto" or something
alike).


Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/initscripts-ng-devel/attachments/20080921/8f7994ed/attachment.pgp