Hi micah, Sorry for the very late reply.
On Thu, Mar 10, 2011 at 04:53:57PM -0500, micah anderson wrote: > # update-rc.d -f ssh remove > update-rc.d: using dependency based boot sequencing > # echo $? > 0 > # update-rc.d ssh disable > update-rc.d: using dependency based boot sequencing > update-rc.d: error: no runlevel symlinks to modify, aborting! > # echo $? > 1 > # invoke-rc.d --query ssh start > 105 > > (note 105 is behavior uncertain) Indeed, you are absolutely right, I confirm the above. With my very limited, only on dependency-based booting-enabled, systems, it seems that update-rc.d $foo enable counteracts update-rc.d $foo disable properly, as long as you don't call "remove" at any point. So, removing the update_rc "-f", @resource[:name], "remove" line before "enable" should be fine. However, I'm not sure how that would interact with systems upgraded from lenny. I'll check that and get back to you, hopefully soon. > So... I'm a little puzzled about what the right way to do this is. Is > using insserv directly the right way to do this? Can we count on insserv > being available on all squeeze systems, and dependency-based initscripts > enabled? What if they are not? I'm not sure about that. Doesn't seem right in any way. FWIW, there's a related discussion at debian-devel these days, see <20110304113539.ga10...@upsilon.cc>. > This would also make backporting to lenny a problem because "update-rc.d > foo {en,dis}able' would not work right, but this is less of a concern. I guess you can document that and change that back, for the limited time that lenny would still live. Regards, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org