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

Reply via email to