Hi, Le 01/03/2014 00:45, Matthew Vernon a écrit : > 2. Loose coupling of init systems > > In general, software may not require a specific init system to be > pid 1. 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 > > provided that these are not themselves required by other software > whose main purpose is not the operation of a specific init system. > > Degraded operation with some init systems is tolerable, so long as > the degradation is no worse than what the Debian project would > consider a tolerable (non-RC) bug even if it were affecting all > users. So the lack of support for a particular init system does not > excuse a bug nor reduce its severity; but conversely, nor is a bug > more serious simply because it is an incompatibility of some software > with some init system(s). > > Maintainers are encouraged to accept technically sound patches > to enable improved interoperation with various init systems. I wonder whether this GR has the following corollary: "Packages shipping services or daemons must ensure that such services are started and stopped with the same defaults under the various init systems." This corollary itself means two things: "Packages shipping services or daemons must continue shipping functional Sys-V style RC scripts", which I think is good, and "Packages shipping services or daemons must ship whatever is required to start and stop said service by any init system introduced in Debian in the past and future", which I think would be bad. Also, is that OK for a package to Recommend a specific init system rather that Depend on it? Kind regards, Thibaut.
Attachment:
signature.asc
Description: OpenPGP digital signature