On Sat, Oct 26, 2013 at 10:46:38AM -0700, Russ Allbery wrote: > Steve Langasek <vorlon@debian.org> writes: > > I don't think either of these are the right question. Even if we change > > the default init system for jessie, because we *must* support backwards > > compatibility with sysvinit for upgrades, there is no justification for > > requiring packages to do anything else for jessie and no policy change > > is needed. > That isn't obvious to me. We have, in the past, allowed upgrades to > require a preliminary upgrade of one or more packages. The udev > transition comes to mind. udev transitions have always happened under duress. We should do better than this where we reasonably can. (In the udev case, we had no choice but to require a risky lockstep upgrade of the kernel and udev, because maintaining udev compatibility with older kernels would have required an excessive amount of new work.) > We *could* do the same thing here and require an init upgrade as a > pre-upgrade step when going from wheezy to jessie, alongside a dependency > on systemd or upstart (added by debhelper, for example) for all packages > providing startup configuration but not an init script. I'm not saying > that's necessarily a good option, but it is an option that we should > discuss. Ok, point taken. We *could* decide that something other than sysvinit was now the new least common denominator for jessie, and using dependencies ensure a smooth upgrade (i.e., this still wouldn't be the udev problem). I think that would be a surprisingly bold change for Debian to make in the space of a single release cycle, when up to now we collectively have very little experience running either systemd or upstart in production on Debian, and we don't as yet have a resolution for compatibility with non-Linux ports. > Also, we will eventually have to decide whether to drop the requirement > that packages provide sysvinit-compatible init scripts. Even if we agree > on a requirement to do so for jessie, we could drop that requirement for > jessie+1 (and indeed will want to if we choose any init system other than > sysvinit or "all of the above," given that most of the benefits of either > upstart or systemd from a packaging perspective will only be seen when we > take that step). > We could always defer that decision until jessie+1, but that's the > decision with the most impact on kFreeBSD and Hurd, and if I were them, > I'd want to know whether that's the eventual project direction or not as > soon as possible so that I have as much time as possible to decide on my > next steps. Right. Whichever init system we pick, I do expect the next step to be to drop the requirement to maintain sysvinit backwards-compatibility; my point was that I don't expect this to be something we change in policy for this cycle as part of the TC decision. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature