Ian Jackson <ijack...@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 (r...@debian.org) <https://www.eyrie.org/~eagle/>