On 3/17/08, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > I suspect the problem is the missing headers in the sysklogd script, > and ignoring it is not going to work. This is a problem in the > transition phase when dependency based boot sequencing is introduced. > When the switch is done, no script without the header will be allowed > to be inserted, and thus the obsolete scripts are safe to leave > behind.
Won't this also be a problem when future script dependencies change? If a package's dependencies change simultaneous with other packages, so that mixing versions of them introduces a circular dependency, then an old version of one of the packages in state "rc" will break my system as well. So this isn't just a problem for the transition stage. It would be different if this just some oddness in unstable/testing; then I'd be fine with fixing it up by hand. It seems to me, though, that this is going to continue to affect all Debian installations (including stable->stable upgrades). You can't honestly say that the dependencies for packages will never change once the transition is complete and all init scripts have these headers. > The reason this issue can not be ignored for removed but put purged > packages, is that the set of symlinks in /etc/rcX.d/ is considered > configuration, and which runlevels a given script is activated for > need to be remembered until it is purged. But aren't you reordering all those symlinks _anyway_ when insserv runs, destroying that configuration information? Or is that not how it works? > I recommend purging all the packages > with init.d scripts that have been removed but not purged. Well, but what if I want to keep their configuration around? It seems bad for insserv to make a new requirement for my system simply because it doesn't feel like handling this case properly :-). > One way to work around this issue in the transition phase would be for > insserv to include an override file for all scripts that do not use a > header identical to the default, to make sure scripts left behind get > their proper location in the boot sequence. I'm not convinced this is > a good idea, as it might hide problems and the script dependencies > should be checked by someone that need the package. That sounds bad, yes. The information should be stored in the packages, not centralized in an insserv configuration. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
