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

Bug#727708: init system resolution - revised proposal



A couple of comments inline below.

Ian Jackson wrote:
> == dependencies rider version T (Tight coupling) ==
> 
>    This decision is limited to selecting a default initsystem; we
>    continue to welcome contributions of support for all init systems.
> 
>    Software may require a specific init system to be pid 1.
> 
>    However, where feasible, software should interoperate with
>    all init systems; maintainers are encouraged to accept
>    technically sound patches to enable interoperation, even if it
>    results in degraded operation while running under the init system
>    the patch enables interoperation with.
> 
> == dependencies rider version L (Loose coupling) ==
> 
>    This decision is limited to selecting a default initsystem; we
>    continue to welcome contributions of support for all init systems.
> 
>    Software outside of an init system's implementation may not require
>    a specific init system to be pid 1, although degraded operation is
>    tolerable.

There is an issue with this wording, which I don't think is intended.
Sometimes, the easiest way to maintain support for multiple init systems
involves having a family of packages, each of which enables support for
one init system or family of init systems.  For instance, consider a
gnome-session-systemd package which uses systemd user sessions, provided
in parallel with a compatibility package that does not.  Or, consider
the systemd-shim package.  As written, this clause would prohibit such
alternative packages, even though *collectively* the packages satisfy
this requirement.  I would suggest adding language like the following,
optionally with the following [non-binding] example:

   Packages which form part of a set of alternatives integrating with
   different init systems need not individually run on other init
   systems, as long as the packages collectively meet the requirements
   of this section.  [ For example, a package using systemd to launch a
   user session, provided as an alternative to a package that runs on
   sysvinit, need not itself run on sysvinit. ]

- Josh Triplett


Reply to: