Re: Transition plan for changing the default init system
]] Ansgar Burchardt
> Tollef Fog Heen <email@example.com> 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 .
> 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
> 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