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

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.

Reply to: