Hi, On 03/01/2014 00:45, Matthew Vernon wrote: > 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.
So if someone packages a new init system that is not compatible with existing init scripts (e.g. if it does not support /etc/init.d/* as a fallback), then it won't be able to start any service. Being not able to start a service with a given init system is probably not a tolerable bug. So by providing a new init system, one can make all packages providing daemon startup files for other init systems instantly buggy? I doubt this is the intention, but the current wording seems to say so. In addition I would find it nice if the full text of the effective changes would be included somewhere in the resolution, for example in a seperate section at the end. Having only a diff makes things more confusing, especially when one references the GR text at a later time. Ansgar -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
