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

Kel Modderman kel at otaku42.de
Mon Sep 22 07:38:31 UTC 2008


On Monday 22 September 2008 16:01:43 Michael Biebl wrote:
> Kel Modderman wrote:
> > 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.
> 
> Done
> 
> > Sorry for the inconvenience, response to comments below:
> > 
> > On Sunday 21 September 2008 13:48:09 Michael Biebl wrote:
> >> 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.
> > 
> 
> Another idea instead of a separate state file would be to extend the LSB
> header.
> We already have the information in there, in which runlevels to start
> (for insserv). We could define a X-Debian-something header, which lists
> the start/stop priorities.
> 
> This would basically be, what Red Hat has traditionally done, with
> chkconfig.
> 
> This of course would be a more invasive approach, as it required to
> touch all initscripts (again).
> It would also make the
> update-rc.d foo start ... stop ...
> interface sort of obsolete. (it sort of is already with insserv).

I agree, out of all the interfaces the one I personally desire the most is
ability to disable a service, and being able to re- enable a service to correct
defaults which may have changed due to package upgrade would be a bonus.

The from .. to .. was a low hanging fruit I saw after making tiny modifications
to the functions that manage the symlinks within update-rc.d.

> 
> 
> What do you think about this idea? Crap or something to discuss further?

I just fear we missed the perfect moment of opportunity, when all init.d
headers initially had the LSB stuff added. I guess lintian could make warnings
and huge amounts of bug reports could eventually achieve this, but that means
another release cycle before most scripts would have this. During which
time insserv and dependency based boot seems more attractive for me to focus
on.

Thanks, Kel.



More information about the initscripts-ng-devel mailing list