Re: Integration with systemd
Hi,
On Wed, Oct 30, 2019 at 05:17:57PM -0700, Russ Allbery wrote:
> 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.
>From an integration point of view we need to make sure that software that
is installed also works, and I have little trouble when packages declare an
explicit dependency on systemd running as pid 1. They need to declare a
dependency nonetheless, because init systems have never been Essential, and
also because the dependency likely needs a minimum version.
There is no point for Debian in taking a stance against using systemd
features, because upstreams will do that anyway, and we neither have the
manpower as a volunteer project to provide alternatives, nor as a
distribution the duty to.
Our goal is to provide packages that allow you to put together a working
system. If upstream decides that their software will only work with
systemd, we make note of that and move on. We already have enough work to
deal with the fallout in our own infrastructure -- I've mentioned
earlier[1] that libgtk-3-0 pulls in systemd-sysv, so autobuilders will
install it quite often, and we need to make sure this doesn't break
anything.
However, a lot of our software comes from the BSD world and will never
fully switch to systemd, and that software is often used in server contexts
by people who know exactly what they are doing. I don't see why we
shouldn't support these people anymore, especially as they are the ones who
cannot be served equally well by other distributions.
> > 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.
Not quite, I think. The goal is to allow people to omit complexity from
features they will not use. My laptop will never automount USB sticks, so
the code path for that doesn't even need to exist. My web server will die
in a horrible way if someone finds a buffer overflow in the SSL code, and
it will stay down until I can manually investigate, there is no code path
that will give the attacker another chance to get the offset right.
The freedom to configure a system without things I do not want is one of
the main reasons that made me switch over from Windows to Debian, a bit
more than twenty years ago.
> 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.
That is work we have to do regardless of whether we want to support
alternatives or not, but in the simple case we just list what is supported
by the systemd version we have decided to ship in the last stable release,
so we can have backport packages with reasonable effort.
Infrastructure I'd like to see is
- dh_systemd generating a versioned dependency for the unit files given
- apt being able to blacklist packages and hide packages that depend on
those
This cuts both ways: for packages with optional systemd integration, I'd
expect "sysvinit" variants to pop up, and we don't want users running
systemd to accidentally install these if a tighter integrated variant is
available.
> 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."
No, and that's not our job. There are a lot of people out there building
non-systemd systems. We do what we've always done, packaging them to the
best of our ability.
Simon
[1] https://lists.debian.org/debian-devel/2019/08/msg00278.html
Reply to: