Re: Integration with systemd

[Simon Richter <sjr@debian.org>]

Hi,

On Thu, Oct 31, 2019 at 04:32:28PM -0400, Theodore Y. Ts'o wrote:

> That's true SO FAR.  The fact remains that systemd has *tons* and
> *tons* of new features which to date, aren't yet getting used in huge
> numbers of open source software packages or in Debian packaging --- YET.

I think that the open source world splitting between systemd and
non-systemd is pretty much unavoidable by now.

Systemd will not go away, and the BSDs plus a few stragglers on Linux are
keeping non-systemd alive as well.

The question for us as a project is whether we want to ship both branches,
or drop the non-systemd branch and shunt off the users to Devuan.

If we do, we should probably decide that before the next release, while it
is still easy for users to migrate (switch to sysvinit in Debian first,
then change the sources.list).

> If we do need to have a GR, we need to be very careful how the choices
> are worded.  We should be clear whether we are giving carte blanche
> for Debian developers to use every possible systemd feature under the
> sun, whether or not there are non-systemd emulation possibilities yet.

Taking off the "I'm running sysvinit" hat, and putting on the "if we're
going to do this, we should at least do it properly" hat: The obvious
middle ground would be to allow features that exist in the previous
release, so we can have working backports.

Whether emulation for these features is implemented for non-systemd is
secondary. If it doesn't work, we lock out the package combination, and
that's it.

IMO, emulation is a red herring for most features.

It absolutely makes sense to teach start-stop-daemon to parse a .service
file instead of its command line, that is a net win for everyone. If unit
files can have shebang lines, we could even use them as init scripts
directly, and that would probably cover 90% of use cases for bullseye
without adding any more emulation features.

I can even see socket activation being emulated to some extent, even though
I'm personally not interested in that beyond saving a few kilobytes on my
laptop by demand-starting lpd), but the ratio of usefulness vs complexity
diminishes quickly after that.

> Again, look at Josh's list of all of the random esoteric systemd
> features that people *could* be using.  I think you're painting a far
> too optismistic picture that there will always be enough programmer
> interest to keep up with systemd's many and varied new features.

The disagreement about systemd is not about whether these features should
be better implemented in C or in shell scripts, but about whether building
such a complex stack is worthwhile, because every layer introduces new and
interesting failure modes, and makes it more difficult to learn how the
entire system works.

So for me it is obvious that there will never be full emulation, because
that would give us the worst of both worlds, complexity without a system
designed from the ground up to organize it.

   Simon