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?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ initscripts-ng-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel
