[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal - preserve freedom of choice of init systems


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.


Reply to: