Hi Christian, Thanks for considering my negative feedback in a constructive way.
On Thu, Dec 29, 2016 at 05:24:26PM +0100, Christian Seiler wrote: > Hi Andreas, [....] > > 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. Looking forward to it. > > - 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.) Yes, but note: sysvinit-utils is still Essential: yes and I think it's too late to change that now for Stretch. According to policy nothing should declare a dependency against an essential package... > > - 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.) (Not sure this is needed, but no objection from me.) > > For Buster: step 0 would be to have someone work out how we can drop Essential: yes from sysvinit-utils. (Should be easily doable, but as always with these things someone needs to make up a plan and consider all cases carefully.) > > - 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.) Installing sysvinit-utils manually will be the least of your problem with invoking the init script directly unless the LSB hook is there to redirect you to systemctl. I think your explanation above is just too complicated for most maintainers to spend enough time/thought about it to get it right. Lets just say "if you use init-d-script provide a matching/masking native systemd service unit" (and even if you don't use init-d-script still provide a matching/masking systemd service unit anyway). Much less complicated IMHO. > > 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? I think we can aim for this (and more!) for Buster. HTH. Thanks for your interest in building a good long-term plan for these issues. Regards, Andreas Henriksson