On Wednesday 20 February 2008, you wrote: > Can I close this BTS report as fixed now, or is there any more I can > do to address it?
Well, let me put it like this. Personally I still think this is a design error: a program should really only need a single verification run for something like this. In your reply to #466700 you said: > > Even if the root cause is an error in the headers of one of the init > > scripts, I really dislike the fact that insserv can leave my system > > in a (for the user) unknown state. > This is also the case for scripts being inserted into the wrong boot > location, but when that is done, it is not easy to detect the problem. However, for the current system at least I know that if I install a single package only the init scripts of _that_ package change. With insserv potentially multiple packages can have major changes if the relationships are complex. This is what makes it more "dangerous", or at least uncertain to me: if something goes wrong which is _not_ detected (because there is no technical (detectable) error in the definitions, but there is a logical one), it can potentially be a lot harder to debug and correct. After my experiences with insserv over the past few weeks, my opinion is that it will not be ready for the big time until: - dpkg triggers has been implemented so that insserv only needs to be run _once_ at the end of an upgrade instead of for each package that changes an init script (at least, I expect that's what it does now) - insserv uses *debconf* to communicate issues (failures, not info) to the user, including the status of the system (e.g. "no changes have been made, existing init procedure is unchanged", or "failure halfway through update of scripts, system may not boot correctly") - insserv creates a log file that details what changes were made during a run so users can actually see what changed in the run order in case of problems; currently AFAIK there is no such info and the only thing you can "see" is the current (broken) state The first point would somewhat mitigate the original subject of this BR, but does not solve it. Feel free to turn this into a wishlist report for those suggestions. Note that I have not really looked into insserv very deeply. This is just based on my experiences as a (dumb) user. Cheers, FJP
signature.asc
Description: This is a digitally signed message part.
