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). What do you think about this idea? Crap or something to discuss further? 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
