[Pkg-sysvinit-devel] Bug #826214: Bug #826215: init-d-script and systemd: solution

[Martin Pitt]

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)