[Pkg-puppet-devel] Bug#573551: affects squeeze, package has only been updated in testing

[Faidon Liambotis]

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.GA10734 at 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