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

[Christian Seiler]

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