Re: Integration with systemd

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

Russ Allbery writes:
> Josh Triplett <josh@joshtriplett.org> writes:
>
>> Part of the problem is that the people interested in sysvinit don't tend
>> to care about those features and often argue that others shouldn't care
>> either, and the people interested in those features don't tend to care
>> about sysvinit. It's difficult to motivate people to work on
>> alternatives for a system they already have and prefer.
>
> *This* is the thing that I feel we need to tackle head-on.  Because there
> are a lot of reasons to care about those features, but possibly more
> convincingly, as Ted points out, *upstreams* care about those features and
> are not going to stop caring about those features just because Debian
> packagers do not.

But many people *don't* care.  See the history of consolekit and
systemd-shim which nobody wanted to maintain and then were unhappy when
they were eventually gone...  The argument there has always been "I
don't care about these features", but upstream projects used them and
eventually systemd was the only implementation.

>> It seems evident based on the history of such efforts that there is
>> *not* sufficient people/interest/motivation to reimplement the majority
>> of systemd features, let alone doing so in a way that meets the
>> additional constraints imposed on such solutions.
>
> I don't think the question has yet been forced.  Up through buster, one
> has been able to mostly run Debian on sysvinit without doing this work,
> with some pain and some gaps and some issues.  I think we're coming up to
> a point where this issue will be forced because both packaging practices
> and upstreams are diverging away from sysvinit support.
>
> I think there are two questions here:
>
> 1. Do we as a project want to do the work to leave open the possibility
>    that such resources will materialize?  This means doing things like
>    defining a subset of systemd unit features that packages can rely on,
>    and requiring (some? all?) packages not use features outside of that
>    set.  "No" is a possible answer here, but this is a political question
>    with significant consequences, and I think it should be decided
>    democratically.

Is there someone willing to do the work you envision?  If not, what
would be the use of deciding about it democratically?

I think we shouldn't spend large amounts of resources to provide support
for such a hypothetical possibility.

I can imaging doing the same for other system interfaces, such as
mandating only a subset of the Linux kernel API to be used to support
alternative implementations of that API.  These already exist,
e.g. Microsoft's Linux subsystem (the old one) and I believe BSDs also
can pretend to be a Linux kernel.

We could also standardize the libc ABI to allow alternative
implementations, or at least not use non-standard extensions that make
replacing glibc harder.

I don't see why systemd should be treated different from other parts of
Debian.

> 2. Are we as a project *capable* of producing a non-systemd alternative
>    that's viable?  If the answer to question 1 is "no," then this question
>    doesn't arise.  But it's entirely possible that the answer to question
>    1 is "yes" but the answer to this question is still "no."

I don't really believe writing init systems is Debian's goal, just like
implementing our own X server or other stuff.

That other implementations that use systemd's unit files might be
useful, but so far no other implementation has come into existence for
years.

Ansgar