"Alexander E. Patrakov" <patra...@gmail.com> writes: > Uoti Urpala wrote:
>> Suppose an upstream releases a new daemon that is intended to be used >> with systemd using socket activation, and as such does not contain any >> code to do double-forking or open listening sockets. Would it be >> forbidden to package this daemon in Debian unless the maintainers are >> willing to add forking, other startup and socket code as Debian- >> specific patches? > Wrong question. As an author of one closed-source daemon that indeed > does not implement double-forking, I made my unofficial Debian package > depend on the "daemon" package. Result: the "daemon" utility performs > that double-forking dance for me and restarts my daemon if it crashes. > If the restart-on-crash functionality is not wanted, then the regular > start-stop-daemon should be sufficient. This is fine for daemons that don't fork (as you say, start-stop-daemon is probably adequate), but less appealing for daemons that are written to require socket activation. You would basically have to write the socket binding code that systemd provides. That being said, this problem seems fairly theoretical. I'm not aware of any upstream code that *requires* socket activation and that people want to package for Debian for jessie, so I'm inclined to err on the side of supporting interoperability with sysvinit for the next stable. If the problem later comes up, we can always take a look. If we select either upstart or systemd, we're going to be taking a rather dramatic step forward. I don't think there's a need to rush it too much, and there are some major advantages in allowing users to switch back to sysvinit in jessie if they need to. (More on that in a later message.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
