Re: Draft text on Init Systems GR
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Russ Allbery writes ("Re: Draft text on Init Systems GR"):
>> As Policy editor, I would interpret "designed to work exclusively with
>> systemd" as including any software that, upstream, had a hard
>> dependency on a systemd feature. That includes obvious things like
>> logind, but also daemons meant to only work with socket activation, any
>> early-boot packages that expect systemd behavior and are only tested
>> with systemd, or software that relies on systemd sandboxing and would
>> be RC-buggy without it.
> Right. But, taking for example, "daemons meant to only work with
> socket activation".
> For many such daemons, it would be easy to patch them to be able to
> work with inetd.
This is true for TCP socket activation, but not as much for D-Bus socket
activation.
> If I wanted to run such a daemon I would probably write that patch,
> along with appropriate inetd.d or whatever.
> Dmitry's current wording would seem to support a maintainer who
> rejected that patch; at least, it wouldn't make failing to take it RC.
Right, that's my understanding as well. I believe Dmitry's wording would
require that the sysvinit community write a wrapper program that exposes
the systemd socket activation protocol, rather than expecting each
maintainer to take patches that support inetd. (I don't think that would
be horribly difficult to do.)
To be clear, I think that's good. A sysvinit implementation of the
systemd socket activation protocol is a better path forward, since I think
it turns this fight into a bug (there is a specific program missing that
can be written, and once it's written, this stops being an issue in
general). Expecting each package maintainer to carry patches to support
inetd is a harder sell.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: