On 18/10/14 at 04:14 +0200, Jonas Smedegaard wrote:
> Thanks a lot for your analysis, Lucas. I find it _very_ helpful!
>
> Quoting Lucas Nussbaum (2014-10-17 22:23:14)
> > 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)
>
> I disagree with your interpretation that _all_ alternative init systems
> are mandatory to support. Remove the "all" in the sentence, and it fits
> my interpretation of the proposal.
>
> @Ian: Probably wise to rephrase to avoid ambiguity here!
[ Disclaimer: I put forward another proposal, but I don't care which one wins
in the end provided it is what is best for Debian; I also disagree with the use
of 'freedom' to characterize the technical ability to switch between init
systems, but for clarity, I'm using 'freedom' in this email ]
Given the motivations for the original proposal:
> This GR seeks to preserve the freedom of our users now to select an
> init system of their choice, and the project's freedom to select a
> different init system in the future. It will avoid Debian becoming
> accidentally locked in to a particular init system (for example,
> because so much unrelated software has ended up depending on a
> particular init system that the burden of effort required to change
> init system becomes too great). A number of init systems exist, and
> it is clear that there is not yet broad consensus as to what the
> best init system might look like.
I don't think that it's useful to change this rule to:
packages MUST work with at least one alternative init system as PID 1
or
packages MUST work with some alternative init systems as PID 1
We could end up with different packages choosing different alternative init
systems, or with a systemd-fork-with-the-same-interfaces-and-formats init
system that makes it possible to satisfy the rule, while still effectively
removing the 'freedom' to choose an init system that isn't looking like
systemd.
So I think that we are down to two solutions that really preserve the 'freedom'
to choose an init system:
1) packages MUST work with all alternative init systems as PID 1.
That's difficult. It means that if someone introduces a new init system with
incompatible interfaces, it requires all maintainers to adjust their packages.
So that rule would only make sense with many additional restrictions.
2) packages MUST work with a specific interface, which is basic enough to
enable all alternative init systems to support it. The most natural such
interface is currently sysvinit: if a package works with sysvinit as PID 1, it
currently also works with upstart, openrc, etc.
If we agree with the mostly uncontroversial answers:
- packages MUST work with the default init system on Linux (Q1)
- maintainers should be encouraged to accept patches that add or improve
support for alternative init systems (Q4), especially when that alternative
init system is the default on a non-Linux port (Q5)
Then I think that the central question in this GR could be reduced to the
following options:
a) we say nothing about alternative init systems. wheezy->jessie upgrades
might require switching to systemd, rebooting, and then upgrading other
packages to keep a functional system
b.1) sysvinit must be supported in jessie by packages that were in wheezy
(that is what is closest to my original proposal)
b.2) sysvinit must be supported in jessie by all packages; we don't say
anything for jessie+1
(that is the minimum proposal that preserves freedom to choose init
system in jessie)
b.3) sysvinit must be supported by all packages (in jessie, but also in the future)
(that is the minimum proposal that preserves freedom to choose init system
on the longer term, which I understand is Ian's motivation for having that vote
now, according to <21569.19669.726247.130490@chiark.greenend.org.uk>)
c.1) all init systems must be supported by all packages in jessie (nothing said
about jessie+1)
c.2) all init systems must be supported by all packages (in jessie, but also
in the future)
I believe that if we voted with those options, it would give us a good idea of
how much we value the 'freedom' to choose an alternative init system, compared to the
additional work required for supporting them.
Options (a), (b.1), (b.2), (c.1) would not incur any additional work,
given that they are limited to jessie, and the current state of jessie
is fine AFAIK.
An additional option, addressing answer A1.2 to Q1, could be required:
@) support for the default init system is not mandatory
But I suspect that it is so controversial that it's not worth putting on
the ballot.
Ian, do you agree that this correctly captures your opinion and the set of
available options?
What do you think of withdrawing both your and my proposal, and designing a
ballot based on the above set of options (re-adding all the small details that
I left out for clarity, e.g. what amount of degraded operation is acceptable,
what are the exceptions, etc)?
Lucas
Attachment:
signature.asc
Description: Digital signature