Bug#727708: init system discussion status
On Fri, 2014-01-03 at 10:02 -0800, Nikolaus Rath wrote:
> Ian Jackson <ijackson@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.
Reply to: