Bug#727708: Resolve impasse by focusing on requirements for smooth upgrade
At the risk of being yet another unhelpful member of the peanut gallery,
I believe I see a way to resolve the impasse regarding the "T" and "L"
options on the previous draft resolution. I'm not a DD but I have used
unstable as my principal desktop OS since 1998, I've administered a
handful of server machines running Debian, and for a couple years circa
2008 I was the sponsored maintainer of a package that contained an init
script, so I feel I have a pretty solid handle on relevant bits of how
Debian is put together.
It is my impression, from reading this discussion to date, that no one
is arguing about which init system should be the default anymore; the
current impasse is, as far as I can tell, entirely about the extent to
which other packages should be allowed to depend (either at runtime, or
as a package relationship) on a specific init system. And I think this
particular argument is as unresolvable as it is because, fundamentally,
it's an argument about software that has yet to be written!
Consider GNOME, for example: as best I can tell, upstream has made the
reasonable-from-their-perspective decision to rely on D-Bus APIs which
*could* be provided by anyone, but at present, are only provided by
systemd (the project). People have made various assertions about how
difficult it would be to port the necessary systemd components to run
with some other init system, or to create independent compatible
implementations, but *no one has actually done that yet*, and we don't
know for sure that anyone will. Contrariwise, people have also made
assertions about how hard it would be to port upstart to the Hurd, add
features to OpenRC until it's a serious contender for the default, etc.,
but again, it hasn't been done yet and we don't know if it will be. The
"right" policy for what non-init packages and ports should do is going
to look very different if some of that work gets done versus if it never
happens.
What we *can* know right now, though, is what we're going to have to do
to ensure a smooth upgrade from wheezy. We can know this because it
doesn't change very much depending on that extra work that gets done;
the huge installed base of systems booted by sysvinit puts a limit on
the scope of the change. We have lots and lots of collective experience
with thorny upgrades involving replacing or reorganizing major
components of the system, so we know how to write policies in support of
such upgrades. Moreover, a smooth upgrade experience is (I do most
earnestly hope) something everyone involved agrees we must have, so
requirements clearly grounded in that goal should have no trouble
achieving consensus.
Based on my own experience, I would like to put forward a suggested
outline for a resolution that focuses on this goal:
----
Having been asked to decide the issue, the TC hereby resolves that:
1a. The default init for new installations of jessie architectures based
on the Linux kernel should be [ systemd / upstart / decided by GR ].
1b. The default init for new installations of jessie architectures based
on other kernels should be decided by the porters for those kernels.
In order to ensure smooth upgrades from wheezy to jessie, and in order
to facilitate testing and experimentation with init systems which are
new to Debian in the jessie cycle, the TC also makes the following
recommendations for Policy:
2a. All init systems shipped in a specific architecture must be
simultaneously installable. Naturally, only one of them will be active
at a time on any given installation.
2b. No package may, merely by being installed or upgraded, cause the
active init to change.
2c. All init systems in Debian must support a common mechanism (similar
in spirit to /etc/alternatives) whereby the administrator of a
particular installation can change the active init. This change may, if
necessary, require a reboot.
3. Packages that require functionality provided by only some of the init
systems in Debian may declare a package dependency on those init systems
in the normal manner. However, as this package dependency will not (per
2b) cause the requested init to become *active*, all such packages must
cope at runtime with the active init not being the one they want.
Failure to do so shall be considered a bug, but the severity of this bug
shall be determined on a case-by-case basis: in particular, such bugs
are not necessarily release-critical, and may even be 'wishlist'.
4. In jessie, all packages which configure some init system to start
daemons (however this may be accomplished) MUST also include a sysvinit
script to the same effect. Maintainers of packages providing daemons
are strongly encouraged to include appropriate configuration for all
supported init systems.
The TC anticipates that this decision is likely to need to be
substantially revised post-jessie, and hereby delegates authority to do
so for (1) to the d-i maintainers, and (2-4) to the Policy maintainers.
----
Thank you for your consideration.
zw
Reply to: