Hello Christian, Christian Seiler [2016-12-26 0:22 +0100]: > 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.
AFAIK init-d-script isn't being widely used, just by a handful of packages. But you are right of course -- packages shouldn't depend on it because then you couldn't uninstall sysvinit-utils under systemd. So instead, sysvinit-core should depend on it, so that i-d-s is available under SysV. Without such a dependency, under systemd calling /etc/init.d/foo would just throw an error, but that's fine IMHO. > 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. That would be more radical, but I don't actually object to the concept of a generic SysV init script -- I just don't want to have it in the systemd package, that's all :-) Hence my suggestion to just change the current version in sysvinit-utils, instead of duplicating it. Why would that not work? > 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. Right, but as you said under systemd you don't need any of those, and I don't think it should be a long-term goal to keep the /etc/init.d/foo interface if nothing from these scripts will actually be used -- that's what systemctl or "service" are for, which are the official APIs to interact with system services. > 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). OK, right -- it calls the original diverted implementation. Still, this is too much indirection and too hard to maintain IMHO. To be honest, if I was to rule the world, I would just make sure that calling /etc/init.d/foo cleanly errors instead of trying to do something undefined if you call it under systemd. This should be a lot simpler to achieve without diversions and three indirections. If that error is something like "/lib/init/init-d-script not found", then that's at least well-defined (even though it's not a very user friendly error, but *shrug* -- this is to prevent accidental damage only). > I don't think that we should break that as long as we provide init > scripts in packages. I think it's actively harmful to pretend that this is an interface which is both safe and sensible to keep for all eternity.. But let's agree to disagree. :-) Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)