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

Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

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

> 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

Reply to: