Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Ansgar <ansgar@43-1.org>]

Adam Borowski writes:
>   * dependencies on "systemd | other" rather than "other | systemd"; this is
>     a no-op on a systemd system (installed by debootstrap before any
>     non-base packages) but causes apt to force an init+rc switch elsewhere

It's very likely not a no-op on systemd systems as significantly more
people somehow got systemd-shim installed than had sysvinit-core, see
for example [1] which shows that somehow the "no-op" results in
systemd-shim getting installed (which caused problems in the past).

Just because you don't observe unwanted behavior happening right now on
your system doesn't imply it doesn't exist.  And the unwanted behavior
that you say wouldn't happen (as it is supposedly a "no-op") happens on
a scale larger than the entire sysvinit user base here...

Your policykit-1 example would likely also suffer from this: adding
alternative builds doesn't only complicate packaging, but it makes the
dependency relations more complicated.  As we've seen from systemd-shim
it's hard to get this right (and Debian did not get this right); from
memory the policykit-1 dependencies to support alternatives looked more
complicated and fragile than what we had for systemd-shim, so they would
probably result in unwanted behavior more often.

So the policykit maintainers wanting to avoid these problems is
understandable to me (I don't think trying to force maintainers to
accept such patches via a GR (option D) is a good solution either).
It doesn't really help that you pretend that there are no issues with
complex dependencies (as above). At a certain point it doesn't make
sense to repeat saying that to you.

  [1]: https://qa.debian.org/popcon-graph.php?packages=sysvinit-core+systemd-shim&show_installed=on&want_legend=on&beenhere=1

>   * recently added lintian warning requiring maintainers to add a redundant
>     .service file even if an init script it already there.  It doubles the
>     work and makes one of methods not maintainer-tested (some folks won't
>     test init scripts, I won't test .service).  And in most cases doesn't
>     even bring any good.

Having multiple init systems that all just call the same sysvinit script
without taking advantage that their native unit type (whatever it is)
provides seems rather uninteresting to me.  It would just mean we get
different implementations that in the end call the same init scripts (so
not "multiple implementations" at all).

What would be the point of providing, for example, openrc be then?

As you don't use systemd I also doubt you would know which (admittedly
mostly minor) annoyances exactly systemd's sysv-compat layer can cause
and would prefer if you didn't try to block people from improving
things.

Really, going back to a "should we really ship systemd units" discussion
makes me wish we would just drop sysvinit completely so we don't have to
restart any discussion from zero (or the point where any alternative
init system was added to Debian).

Ansgar