Hi Andreas,
Sorry for not replying earlier, but I wanted to mull this over some before answering. On 12/27/2016 10:49 AM, Andreas Henriksson wrote: > 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.) > [...] > > 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. So after reading your arguments I believe I agree with you. > 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. Yes. > I also have to point out that I completely disagree with you on > minimal systems not being relevant to anyone. I think you misunderstood me a bit, I'm not against making the Debian base smaller (I use containers myself and them requiring less stuff is definitely something I look forward to) - but since that was in support of an argument for something I'm now convinced it's not the right way, I'm going to leave it at that. After reading the other emails, maybe we can converge on the following consensus / compromise? For stretch: - I'll provide a patch for #826214 against init-d-script that will restore the original arguments while sourcing /lib/lsb/init-functions. This will make systemctl redirection work again for Stretch when using init-d-script. - We'll ignore #826215 for Stretch and scripts shipping an init-d-script based init script will hard-depend on sysvinit-utils regardless of systemd service availability. (As they do now.) - Add a warning to the output in systemd's /lib/lsb/init-functions.d/40-systemd and mention that calling init scripts directly on systemd systems is deprecated. (I can provide a patch.) For Buster: - We revisit #826215 and say that packages that provide a init-d-script that has the same name as a systemd service need not depend on sysvinit-utils, and that if people want init-d-scripts called directly in /etc/init.d (when a corresponding systemd service also exists) to work on systemd systems, they also have to install sysvinit-utils, otherwise this just breaks. People using service / invoke-rc.d will not have any trouble, and people who really want to call the script directly via /etc/init.d have to install an additional package. (Or use sysvinit as the init system.) For either Buster or Buster + 1: - Revisit init.d script redirection entirely and perhaps get rid of it. (Or not, we'll have to see.) Would at least the Stretch part of that be agreeable for everyone involved here? Regards, Christian PS: I've also gone through the bug list against init-d-script and have been working on fixing a couple of other issues. I haven't posted anything in that regard yet because I wanted to wait what came out of this discussion here first, because this is the most important issue at the moment. _______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
