Bug#727708: init system coupling etc.

[Andreas Barth <aba@ayous.org>]

* Colin Watson (cjwatson@debian.org) [140213 19:09]:
> To start with, I therefore propose the following amendment to L.  I
> think it is no weaker except in ways that we would agree were in fact OK
> if we found ourselves needing to rule on them specifically, and this
> addresses points that people have raised here.  The first paragraph of
> the "loose coupling" section is replaced by the following:
> 
>   In general, software may not require a specific init system to be pid
>   1, although degraded operation is tolerable.  The exceptions to this
>   are as follows:
> 
>    * alternative init system implementations
>    * special-use packages such as managers for init systems
>    * cooperating groups of packages intended for use with specific init
>      systems
I'm not sure if this already covers the case of glue-packages, or if
we need to cover them (i.e. for a package foo, it's ok, if foo depends
on foo-sysv | foo-systemd | foo-upstart | foo-openrc, and each of
those four depends on a specific init system).


>   provided that these are not themselves required by other software
>   whose main purpose is not the operation of a specific init system.

I think we agree that "required" doesn't involve cases where such a
package is just one of a different set of packages which fulfils that
requirement (via virtual packages or alternatives).


> Russ, can you give an example of a package that currently supports
> sysvinit where you would be happy that it might stop supporting it for
> jessie due to a lack of technical feasibility?

If this is advice, I think we can drop that part (for a decision that
might be different, and an indication that it might be possible that
there are exceptions might be appropriate).



Andi