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

[Kel Modderman]

Hey Michael,

I forgot to say in my mail to debian-devel that I do not subscribe to that
list (do subscribe to this one), could you please forward your response
to the "update-rc.d disable|reeneable" thread to me, so I can reply properly
and make clear I need to be cc'd on the debian-devel thread.

Sorry for the inconvenience, response to comments below:

On Sunday 21 September 2008 13:48:09 Michael Biebl wrote:
> 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 think it should be very easy for the maintainer to know which version of a
package they used specific defaults are for, but having to write out this
explicitly in a postinst script is not foolproof, I agree.

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

Yeah. It is an attempt at using the runlevel link scheme as the state.

> 
> 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 .

My approach attempted to sidestep this complexity, and simply leave the admin
on his own when (s)he decided he did not like the package defaults, preserving
all custom changes to the link scheme. But as you point out below, if the admin
then needs to update links to the new scheme because of problems or no
longer needing to maintain the divergence, then where to obtain these new
defaults?

Recording of state to file is probably a good way to do it.

> 
> 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.

Yeah, it would be nice to address this.

> 
> 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).

Okay, I'll have a look at integrating this approach and see what happens.

Thanks, Kel.