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

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory



Hi,

On 17/10/14 at 13:02 +0200, Lucas Nussbaum wrote:
> Actually, I wonder if both proposals shouldn't be rewritten using RFC 2119 to
> make them clearer.

I did not really do that, but instead rewrote both proposals as a set of
Q&A that make it easier to understand the differences and the possible
additional alternatives.

I think that there are 5 different questions, but only Q2 seems to be
really controversial.

For reference, Ian's proposal refers to:
21567.57029.724173.958520@chiark.greenend.org.uk">https://lists.debian.org/21567.57029.724173.958520@chiark.greenend.org.uk
Mine refers to:
20141017074416.GA2520@xanadu.blop.info">https://lists.debian.org/20141017074416.GA2520@xanadu.blop.info


Q1: support for the default init system on Linux
================================================
A1.1: packages MUST work with the default init system on Linux as PID 1.
      (this is the case in both Ian's and my proposal)

A1.2: not proposed yet: no mandatory support for the default init system?
      choice on a per-package/per-maintainer basis?
      (Luca Falavigna's proposal would fit here, I think)


Q2: support for alternative init systems as PID 1
=================================================
A2.1: packages MUST work with all alternative init systems as PID 1.
      (that's Ian's proposal)
      To the user, that brings the freedom to choose any init system,
      with the guarantee that it won't break some packages.
      But it requires the maintainer to support all init systems,
      possibly without upstream cooperation.
      Lack of support is a policy violation (severity >= serious, RC).
      Bugs about degraded operation on some init systems follow the
      normal bug severity rules.

A2.2: packages SHOULD work with alternative init systems as PID 1.
      (that's my proposal)
      This is a recommendation. Lack of support is not a policy
      violation (bug severity < serious, not RC).

A2.3: not proposed yet: say nothing about alternative inits?
      (lack of support would be a wishlist bug?)


Q3: special rule for sysvinit to ease wheezy->jessie upgrades
=============================================================
(only relevant for A2.2)
A3.1: continue support for sysvinit (that's my proposal)
      For the jessie release, all software available in Debian 'wheezy'
      that supports being run under sysvinit should continue to support
      sysvinit unless there is no technically feasible way to do so.

A3.2: not proposed yet: require two-step upgrades, i.e. first reboot
      with systemd, then upgrade other packages?


Q4: non-binding recommendation to maintainers
=============================================
A4.1: recommend that maintainers accept patches that add or improve
      support for alternative init systems. (both Ian's and my proposal
      have something like this, with a different wording)

A4.2: not proposed yet: say nothing


Q5: support for init systems with are the default on non-Linux ports
====================================================================
(only relevant for A2.2)
A5.1: non-binding recommendation to add/improve support with a
      high priority (in my proposal)

A5.2: not proposed yet: say nothing


Hoping this helps someone besides me :-)

Lucas

Attachment: signature.asc
Description: Digital signature


Reply to: