Hello Martin, On 12/25/2016 09:18 PM, Martin Pitt wrote: > Christian Seiler [2016-12-25 13:34 +0100]: >> I think I have a solution to both issues - and my solution >> does not require any change to any individual init script, >> and best of all it doesn't even require changes to any >> sysvinit-related package (we get to have our cake and eat >> it too): > > Thanks for working on this! > >> The systemd package could install a diversion of /lib/init/init-d-script and >> install its own wrapper. > > I don't like this approach, to be honest. (1) This diversion would be present > on practically all installs anyway, as it would (necessarily) be in the > "systemd" binary, not the "systemd-sysv" one. (2) I don't want to maintain > this > SysV stuff in the systemd package forever, AND still have someone else > maintain > the non-diverted variant in sysvinit-utils. I'd much prefer to just change the > "master" copy in sysvinit-utils, and packages which use that should grow a > dependency to that (so that it can become non-essential).
But the reason why you want to make sysvinit-utils non-essential is to be able to remove the package. But if a lot of packages now depend on it, then this will be installed on most installs regardless, so there's no point in making the effort of making it non-essential. (Unless you are really only interested in minimalistic base systems that aren't really useful to anybody.) What's the alternative? Michael proposed to go back to the old template for init scripts in the initial bug report and basically drop init-d-script from packages. As someone who maintains packages that contain daemons, I strongly disagree: one of the appeals of systemd (which I use and like btw.) is that service files are easy to read. Same goes for init scripts that use init-d-script instead of what was there previously, they are much easier to read than the horrible mess that was there previously. His alternative proposal is much better, but apparently not something the init-d-script people want, for understandable reasons, and in addition both suggestions would require that lots of consumers of init-d-script change their code. In the end, you're just distributing a single additional script with the systemd package. The maintenance burden is going to be essentially zero, because the interface of init-d-script can't change without all of the consumers having to be updated. I think the whole integration that makes shutdown while switching init systems work is probably a lot more work than shipping this file + the diversion, even if that diversion is going to be installed on most systems. (Which I don't consider to be a problem, just look at the fact that /bin/sh is a diversion on nearly all installed Debian systems, which is a lot more essential to a running system than init-d-script.) Also, consider the following: with how I wrote this wrapper, if _all_ installed init scripts use init-d-script _and_ have native systemd service equivalents, then /lib/lsb/init-functions and /lib/init/vars.sh also don't have to be installed on systemd systems, because the wrapper will also work in those cases and properly redirect to systemctl there. You can then get rid of all of the sysvinit packages in that case - and just carry two files in the systemd package, /lib/lsb/init-functions.d/40-systemd and the wrapper I created, for compatibility reasons. This will make it quite a bit easier to reduce the amount of installed packages on the system. > I. e. use your script but patch the current one instead of duplicating it. Well, my script doesn't duplicate the init-d-script logic at all. It is just some glue code hat hooks up the upcall to systemctl (but reuses existing code for that), and falls back to the original implementation if systemd isn't used (or another corner case is hit). > If the SysV init maintainers don't want to carry this either, then there's > still the option to just drop the systemd integration, and break calling > /etc/init.d/foo directly under systemd. WDYT? I don't think that we should break that as long as we provide init scripts in packages. That all said: if you just want to fix #826214, I can also provide a patch for the systemd package that updates /lib/lsb/init-functions.d/40-systemd to properly work with init-d-script - without you having to modify init-d-script or any consumer thereof itself. But that won't help for #826215, when it comes to how packages acquire dependencies on sysvinit-utils. Regards, Christian
