On Wed December 29 2010 00:13:04 Camaleón wrote: > AFAIK, booting scripts have been rewrited to play with dependency booting > and provided this is new for Squeeze, I would expect some glitches, but > nothing that cannot be solved.
The question is not whether the problem can be solved. People can as a last resort always hack the source. The immediate question is whether the insserv mess can be reasonably maintained. And the big picture question is whether the ego boost for the insserv developer is worth the substantial hit to Debian's reputation. I'll give you just a few examples that we've run into since this thread started a few hours ago. (1) We cannot find any useful documentation as to who controls /etc/init.d/foo, /etc/insserv/overrides/foo, /etc/insserv.conf.d/foo, /usr/share/insserv/overrides/foo, and /etc/insserv.conf. All of these can be used to specify dependencies. Which are intended for Debian packagers, and which for sysadmins? Which are supported properly through upgrades and dist-upgrades? How are conflicts between the five sources of dependencies handled, i.e. which has priority over which others? You recommended that sysadmins edit /etc/init.d/foo. Is that Debian policy or a kludge that will cause pain on the next upgrade? Would it be better to use one of the many other places where overrides can be specified? (2) There are many kinds of connections and tunnels and routes that need to be established on some boxes but not on others. For example, some servers need ethernet interfaces, then openvpn, then quagga. Others need early PPP although we don't have a test box configured for that right now. Debian Stable handles all this correctly out of the box. After insserv wreaks havoc, openvpn can erroneously be brought up last while apache can fail before openvpn, named, quagga, and mysql are started. Any sane dependency boot system would allow me to say "start openvpn before services X, Y, and Z" but under insserv we're stuck with creating a separate override for each of X, Y, and Z. insserv appears to be a high-school coding experiment, not a professional sysadmin tool. (3) insserv wants to start openvpn before gdm3 on workstations. That's probably a good idea as that's what Debian Stable does. However, although that dependency appears in the generated /etc/init.d/.depend.start we cannot find the source of the dependency. It is not in any of the places listed in (1) above. Are there more special cases hidden somewhere? What if someone needed gdm3 to start before openvpn, how would they override a hidden (possibly hard-coded?) dependency? (4) /etc/init.d/bootlogs describes itself as "Various things that don't need to be done particularly early in the boot, just before getty is run." And yet it has no defined relationship to getty, and defines the opposite relationship to gdm3, kdm, etc. Which is correct, the description or the dependencies? Thanks for looking into this. I still fail to see why saving half a second a year on server booting is worth inflecting days of drudgery on tens of thousands of sysadmins. So yet again, why is Debian forcing this horrible change? The old sysv-rc is not hard to support alongside file-rc. Why abuse the power of Debian dependencies to push this bad idea on sysadmins who don't want it? Why can't we keep the excellent debugged working reliable sysv-rc from Lenny? If some people want to use insserv let them, but don't force people to go through this nonsense! insserv simply throws away all the hard work by Debian Developers over many many years that went into tuning the default rc2.d/Snn priorities. --Mike Bird -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012290137.48863.mgb-deb...@yosemite.net