On Fri, 2014-01-03 at 10:02 -0800, Nikolaus Rath wrote: > Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > > | 3. At least in jessie, unless a satisfactory compatibility approach is > > | developed and deployed (see paragraph 10), packages must continue > > | to provide sysvinit scripts. Lack of a sysvinit script (for a > > | daemon which contains integration with at least one other init > > | system) is an RC bug in jessie. > > > As said elsewhere, I think there should be a paragraph about packages > that depend on a specific init system for reasons other than service > startup, e.g.
Even restricted to just service startup, I think that's a rather strict limitation. 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? If it would, how much functionality would the maintainers need to add for a minimal accepted version - for example would they need to add new options to specify which port to listen on, or is opening a hard-coded default port enough for the added socket code? Adding support for everything that systemd socket activation automatically supports would not be realistic. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
