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. So I'd say: Debian should support daemons that don't contain double-forking or socket-opening code, and should do so without patching such daemons. Patching or providing one Debian-specific utility (e.g. start-stop-daemon) should be enough. Or in other words: it is technically possible to write a Debian-specific "universal readiness protocol translator" that wraps a program that provides one readiness protocol and thus makes it compatible with the init system that expects another protocol. -- Alexander E. Patrakov -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/can_lgv2ccpdmsefxzcdmjo2qebjyg0w5dm4rqbq8zrdgkse...@mail.gmail.com