Hi,
I updated my previous mail breaking down the various proposals in
questions, and published it online [1].
[1] http://www.lucas-nussbaum.net/blog/?p=845
I'm copying it below. I tried to make an accurate and objective summary;
if I'm wrong, please correct me. I'll update the blog post accordingly.
Lucas
-------------------------------------------------------------------->8
This is an update of [1]my previous attempt at summarizing this
discussion. As I proposed one of the amendments, you should not blindly
trust me, of course. :-)
First, let’s address two FAQ:
What is the impact on jessie?
=============================
On the technical level, none. The current state of jessie already
matches what is expected by all proposals. It’s a different story on
the social level.
Why are we voting now, then?
============================
Ian Jackson, who submitted the original proposal, explained his
motivation in [2]this mail.
We now have four different proposals: (summaries are mine)
* [iwj] Original proposal (Ian Jackson): Packages may not (in
general) require one specific init system ([3]Choice 1 one this
page)
* [lucas] Amendment A (Lucas Nussbaum): support for alternative init
systems is desirable but not mandatory ([4]Choice 2 one this page)
* [dktrkranz] Amendment B, probably (Luca Falavigna): Packages may
require a specific init system ([5]Choice 3 one this page)
* [plessy] Amendment C, probably (Charles Plessy): No GR, please;
already resolved ([6]Choice 4 one this page)
[plessy] is the simplest, and does not discuss the questions that the
other proposals are answering, given it considers that they already
have been resolved ([7]even though I disagree with this analysis).
In order to understand the three other proposals, it’s useful to break
them down into several questions.
Q1: support for the default init system on Linux
================================================
A1.1: packages MUST work with the default init system on Linux as PID
1.
(That is the case in both [iwj] and [lucas])
A1.2: packages SHOULD work with the default init system on Linux as PID
1.
With [dktrkranz], it would no longer be required to support the default
init system, as maintainers could choose to require another init system
that the default, if they consider this a prerequisite for its proper
operation; and no patches or other derived works exist in order to
support other init systems. That would not be a policy violation. (see
[8]this mail and [9]its reply for details). Theoretically, it could
also create fragmentation among Debian packages requiring different
init systems: you would not be able to run pkgA and pkgB at the same
time, because they would require different init systems.
Q2: support for alternative init systems as PID 1
=================================================
A2.1: packages MUST work with one alternative init system (in [iwj])
(if you are confused with “one” here, it’s basically fine to read it as
“sysvinit” instead. See [10]this subthread for a discussion about this)
To the user, that brings the freedom to switch init systems (assuming
that the package will not just support two init systems with specific
interfaces, but rather a generic interface common to many init
systems).
However, it might require the maintainer to do the required work to
support additional 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. (in
[lucas])
This is a recommendation. Lack of support is not a policy violation
(bug severity < serious, not RC). A2.3: nothing is said about
alternative init systems (in [dktrkranz]). Lack of support would likely
be a wishlist bug.
Q3: special rule for sysvinit to ease wheezy->jessie upgrades
=============================================================
(this question is implicitly dealt with in [iwj], assuming that one of
the supported init systems is sysvinit)
A3.1: continue support for sysvinit (in [lucas])
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: no requirement to support sysvinit (in [dktrkranz])
Theoretically, this could require two-step upgrades: 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. (in both [iwj] and [lucas], with
a different wording)
A4.2: say nothing (in [dktrkranz])
Q5: support for init systems with are the default on non-Linux ports
====================================================================
A5.1: non-binding recommendation to add/improve support with a high
priority (in [lucas])
A5.2: say nothing (in [iwj] and [dktrkranz])
References
1. 20141017202314.GA9393@xanadu.blop.info">https://lists.debian.org/20141017202314.GA9393@xanadu.blop.info
2. 21569.19669.726247.130490@chiark.greenend.org.uk">https://lists.debian.org/21569.19669.726247.130490@chiark.greenend.org.uk
3. https://www.debian.org/vote/2014/vote_003.en.html
4. https://www.debian.org/vote/2014/vote_003.en.html
5. https://www.debian.org/vote/2014/vote_003.en.html
6. https://www.debian.org/vote/2014/vote_003.en.html
7. 20141021124128.GA5000@xanadu.blop.info">https://lists.debian.org/20141021124128.GA5000@xanadu.blop.info
8. 20141018121349.GA22459@xanadu.blop.info">https://lists.debian.org/20141018121349.GA22459@xanadu.blop.info
9. https://lists.debian.org/CADk7b0PWg4Q5hywg--oq=+fz0OZ3+rpOfLKEajXBOxVBLHdUMw@mail.gmail.com
10. 20141019152736.GB681@xanadu.blop.info">https://lists.debian.org/20141019152736.GB681@xanadu.blop.info
Attachment:
signature.asc
Description: Digital signature