Transition plan for changing the default init system

[Tollef Fog Heen]

]] Ansgar Burchardt 

> Tollef Fog Heen <tfheen at err.no> writes:
> > So we are proposing the following scheme:
> >
> > a/ Upload a new "init" package. This is a new, essential package that
> > will replace sysvinit as the package that ensures your system has an
> > init system. We want to build this binary package from a package which
> > is not tied to an actual init system, so we chose the
> > init-system-helpers source package. Patch for init-system-helpers is
> > available at [2].
> 
> Would it be possible to have "init" not be essential while we are
> already changing things? There are valid use cases for init-less
> systems, for example chroot environments.

At least some packages do assume that binaries like /sbin/runlevel
exist, so dropping Essential: yes would mean a larger cleanup of the
archive.  I'm not opposed to that as such, but I'm not sure we need to
entangle that into this change?

(In most cases, I think people should be using containers and not
chroots, in which case you might want an init, but that's a somewhat
separate discussion.)

[...]

> On kfreebsd, init would then depend on an optional package as we don't
> support arch-specific priorities. That is (IIRC) a policy violation, but
> do any practical problems arise from this?

It would be useful to have a comment from one of the debootstrap
maintainers about this, I think.  That's the only one I can think of
that actually cares much.

Would it be hard to add support for per-arch priorities to dak?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are