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

Bug#727708: init system coupling etc.

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> FORMAL ACTION: I therefore hereby formally propose the following
> resolution ("init system coupling v2"), but do not yet call for votes.

> [rationale]

>    The default init system decision is limited to selecting a default
>    initsystem for jessie.  We expect that Debian will continue to
>    support multiple init systems for the foreseeable future; we
>    continue to welcome contributions of support for all init systems.

> [rubric]

>    Therefore, for jessie and later releases, we exercise our power to
>    set technical policy (Constitution 6.1.1):

> [loose coupling]

>    Software outside of an init system's implementation may not require
>    a specific init system to be pid 1, although degraded operation is
>    tolerable.

>    Maintainers are encouraged to accept technically sound patches
>    to enable improved interoperation with various init systems.

> [GR rider]

>    If the project passes (before the release of jessie) by a General
>    Resolution, a "position statement about issues of the day", on the
>    subject of init systems, the views expressed in that position
>    statement entirely replace the substance of this TC resolution; the
>    TC hereby adopts any such position statement as its own decision.

>    Such a position statement could, for example, use these words:

>       The Project requests (as a position statement under s4.1.5 of the
>       Constitution) that the TC reconsider, and requests that the TC
>       would instead decide as follows:

I propose the following text as an amendment to this option.  It would
replace this text in its entirety, including the [GR rider] section.  (I
don't see any need for or purpose served by cancelling technical advice to
the project based on a GR outcome.  All the members of the project are, I
think, capable of using their own judgement to resolve technical advice
with the substance of a GR, and technical advice is by definition not
binding.  Plus, I think this is a basically sensible thing to say
regardless of the chosen init system.)

Please note that I personally am currently leaning towards voting Keith's
proposal above the one that I'm proposing in this message for the reasons
that he states in that message.  But I think it's useful to have a
statement on the ballot so that it can be ranked, since it may be a
compromise position between deferring to the Policy process and Ian's

    The following is technical advice offered to the project by the
    Technical Committee under section 6.1.5 of the constitution.  It does
    not constitute an override of maintainer decisions past or future:

    Packages should normally support the default Linux init system.  There
    are some exceptional cases where lack of support for the default init
    system may be appropriate, such as alternative init system
    implementations, special-use packages such as managers for non-default
    init systems, and cooperating groups of packages intended for use with
    non-default init systems.  However, package maintainers should be
    aware that a requirement for a non-default init system will mean the
    package will be unusable for most Debian users and should normally be

    Package maintainers are strongly encouraged to merge any contributions
    for support of init systems other than the Linux default, and to add
    that support themselves if they're willing and capable of doing so.
    In particular, package maintainers should put a high priority on
    merging changes to support any init system which is the default on one
    of Debian's non-Linux ports.

    For the jessie release, all packages that currently support being run
    under sysvinit should continue to support sysvinit unless there is no
    technically feasible way to do so.  Reasonable changes to preserve or
    improve sysvinit support should be accepted through the jessie
    release.  There may be some loss of functionality under sysvinit if
    that loss is considered acceptable by the package maintainer and the
    package is still basically functional.  All packages should support
    smooth upgrades from wheezy to jessie, including upgrades done on a
    system booted with sysvinit.

    The Technical Committee offers no advice at this time on requirements
    or package dependencies on specific init systems after the jessie
    release.  There are too many variables at this point to know what the
    correct course of action will be.

I'm also happy to consider amendments to this text along the lines of
Steve's proposed language elsewhere in the thread.

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: