[debhelper-devel] Bug#749400: dh_installinit: disable init scripts on removal of package

[Alan Jenkins]

On 09/06/17 18:55, Niels Thykier wrote:
> Alan Jenkins:
>> On Thu, 24 Dec 2015 00:34:22 -0300 Felipe Sateler <fsateler at debian.org>
>> wrote:
>>
>> [...]
>>
> Hi Alan,

>> Why don't we use `update-rc.d FOO remove` on package removal?  This
>> would simply remove all the symlinks. [...]
>>
> As I read the "update-rc.d" manpage, the symlinks are a part of the
> customization that a admin can do.  So if we remove them, then we remove
> configuration during "remove" (which must only be done during "purge").
> Note this paragraph in update-rc.d(1):
>
> """
> A  common  system administration error is to delete the links with the
> thought that this will "disable" the service, i.e., that this will
> prevent the service from being started.  However, if all links have been
> deleted then the next time the package is upgraded,  the  package's
> postinst  script  will  run update-rc.d  again  and  this will reinstall
> links at their factory default locations.  The correct way to disable
> services is to configure the service as  stopped in all runlevels in
> which it is started by default.  In the System V init system this means
> renaming the service's symbolic links from S to K.
> """
>
>
> Thanks,
> ~Niels

:-(.  I guess my hope was, this bug report showed some sort of 
precedent, that policy did not prevent the idea.  Otherwise, this bug 
would have been shut down earlier on.

I.e. the code running `update-rc.d FOO disable` at removal, would surely 
overwrite the customization done by the admin, but that didn't stop that 
code being pushed to unstable.  (And it's not the reason it was reverted).

Huh, even more confusing: if the package script runs `update-rc.d FOO 
disable` at removal, and then you install the package again and it runs 
`update-rc.d FOO defaults`, I think the init script would stay 
disabled?!  I probably need to stop making assumptions from the history 
of this issue.

It suggests, this proposal would also need to save the enabled state(s) 
at package removal and be able to restore them later... but that's more 
than I'd be willing to implement.

However I can imagine saving a "mask" under /var/lib/update-rc.d/, which 
has a similar disabling effect to a systemd mask. Implementing this in 
/etc/init.d/rc.  And patching the systemd-sysv-generator to match it.

For native systemd services... I would then be able to simply remove all 
the `mask` code in dh_systemd_enable, to solve my issue (described in 
#864504)

Alan