Hello Christian Seiler, On Sun, Dec 25, 2016 at 01:34:41PM +0100, Christian Seiler wrote: > Hi there, > (Cc'd a lot of people, so that hopefully everybody relevant > is included.) [...]
Not sure my opinion on this matter is relevant, but since you CCed me here are my 5 (swedish) öre on this: The problem I pointed you to where only one out of many symptoms of the breakage introduced by using init-d-script. I think just attacking one specific symptom of one specific LSB hook is wrong. What happens when more LSB hooks also wants to use your solution? What happens when 5 different packages all try to divert init-d-script and then call each other in a chain? This won't work or atleast won't be maintainable. Following Martins advice and pushing this back into the original init-d-script is better, because that means this is confined in a single place. At the same time I think that's still wrong... you're still only adding workarounds for one specific LSB hook. At the same time for Buster it might be time to let go of this. Just leave init-d-script broken in this regard (and hopefully find someone willing to maintain it and handle its other issues). But in that case I also think the systemd LSB hook should be changed from seamlessly diverting to systemctl to instead print an error message advocating invoke-rc.d or service and erroring out. I also have to point out that I completely disagree with you on minimal systems not being relevant to anyone. There's been much work done on enabling more minimal systems for Stretch (which now even supports being init-less). This is very useful for containers. At the same time our inability to cater to this need means we're rapidly losing ground to things like Alpine Linux which does a better job at being small atleast. Still, thanks for looking into this! Regards, Andreas Henriksson PS. Likely doesn't make much difference but given sysvinit-utils is so contentless these days making it non-essential in Buster would still be a nice "cleanup" in my opinion. sysvinit-core already has dependency in place (despite sysvinit-utils being essential). Packages shipping init scripts using init-d-script should make sure to also have a native systemd unit masking the init script.
