[debhelper-devel] Bug#864504: dh_systemd_enable: please go back using `disable` instead of `mask`

[Alan Jenkins]

On 16/10/17 16:44, Michael Biebl wrote:
> Am 16.10.2017 um 12:40 schrieb Alan Jenkins:
>
>> I suspect this would end up with Debian carrying the patch to the
>> systemd generator.  But all it needs to do is test for
>> `/var/lib/update-rc.d/${script}.removed` and then skip ${script}.
>>
>> Alan
> I'm not very enthusiastic of keeping and maintaining (yet another) state
> directory/file which could potentially get out-of-sync .
>
> A much simpler idea could be, to remove the -x bit from the SysV init
> script on remove (and reapply it on re-install). Afair, the
> sysv-generator already ignores such init scripts. So nothing would have
> to change on the systemd side.
>
> dh_installinit (shipped by debhelper) would have to be updated to
> generate maintainer scripts code to remove and (re)add the executable bit.
>
> Still, we'd have to consider that we have upgraded systems which have
> not been rebuilt with the new debhelper so we can't just remove the
> current logic which masks uninstalled-but-not-purged init scripts.
>
> Maybe in two or three releases we could revisit that.
>
> Removing the -x bit of removed-but-not-purged init scripts would have
> the nice side effect, that those are also not executed under
> sysvinit/startpar.
>
> Are you interested in working on a patch for debhelper?

Sorry.  I thought I should report my annoyance once I'd found the root 
cause for it.  But I don't think I can commit to writing patch(es) now.

Maybe you have the right idea about clobbering the executable bit. I 
didn't like it because the reason for this annoyance was just such a 
clobbering (v.s. systemctl mask).

It was already frustrating to prevent a Debian network service starting 
before you'd configured it.[1]  `systemctl mask` provides a way to do 
it.  For sysvinit, presumably assigning -x with `dpkg-statoverride` 
would be an equivalent.  Perhaps not a well-documented one.  Such 
procedures could be silently defeated if the install script applies +x.

[1] 
https://unix.stackexchange.com/questions/321621/configuring-my-sshd-securely-with-automation/321622

 > we can't just remove the current logic which masks 
uninstalled-but-not-purged init scripts

Ouch, I'd forgotten about the transition issue.  Yep, I guess wait for 
long enough and then explain it in a release note.   (Or write an even 
more magic package script to apply the mask to residual conffiles in 
/etc/rc.d).

Alan