Re: Integration with systemd
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.
Sure, some systemd features are only marginally better than what came
before (I admit to not being much of a fan of timer units, for instance).
But this will vary by person. For example, as a security person, I care a
*lot* about namespacing, capability reduction, and seccomp filters, and I
want to use those features in my packages to make the default
configuration more secure. Other people are going to care a lot about
D-Bus integration, and some upstreams are going to fully embrace socket
activation (which, again, I'll point out is one of the easiest features of
systemd to implement outside of systemd; implementations of the same idea
predated systemd by many years) and just not support any way of spawning
their service that doesn't satisfy the systemd socket activation API.
One can individually say that one doesn't care about those features, but
we just cannot say Debian as a whole should not care about those features.
It doesn't work. We have to take an affirmative stance on what Debian is
going to do with software that does care about and use those features;
whether we're committing to porting it, whether we're going to kick it out
of the archive (that seems highly unlikely to be viable), whether we're
going to say that software with a hard dependency on systemd features is
allowed to only work on systems running systemd, or some other
alternative.
But saying "no one should care about those features" isn't a choice and
isn't a path forward and we can't stop there as a project.
> That's leaving aside that a reimplementation of systemd's features will
> tend towards becoming systemd, and we have one of those already. What is
> the actual goal?
The actual goal is to allow for different ecosystems that provide the same
features while embracing different implementation philosophies. I know
that you don't think this is a valuable goal; please let's not have that
argument yet again. I'm sure you realize by now that some people simply
do not agree with you and do not find your arguments convincing.
> 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.
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."
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: