Re: Proposal - preserve freedom of choice of init systems
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
Reply to: