Bug#923450: tech-ctte: requirements for being pre-dependency of bin:init
On Thu, 28 Feb 2019 at 12:06:15 +0000, Dmitry Bogatov wrote:
> currently, inclusion of new init system into Debian requires inclusion into
> pre-dependency of bin:init package, which is unsatisfactory.
>
> As can be followed in #838480, current practice puts maintainer of any
> new init system to be included into Debian at disadvantage, essentially
> granting maintainer of bin:init (which happens to be `systemd' team now)
> veto right. According to Constitution 3.1, individual developer poses
> power of descision making only with regard their /own/ work.
>
> Hereby, I ask TCCE to provide requirements init system must satisfy that
> /warrants/ inclusion into pre-dependency of essential bin:init.
> Alternatively, I ask to consider introducion of virtual package
> 'init-system'.
We discussed this at last month's technical committee meeting (sorry for
the delay in replying - I've been busy IRL, and so was the person previously
asked to reply).
Committee consensus
-------------------
Yes, we agree that the maintainers of the init-system-helpers package
(which builds the init binary) have a gatekeeper role for making init
systems as straightforward to install to /sbin/init as e.g. sysvinit is.
We don't consider this to be a problem. They seem to be applying due
scrutiny and care to this process, based in part on experience that they
gained during systemd's time as an unsupported/non-default init system.
We would recommend that the init-system-helpers maintainers should
document their requirements for being an alternative pre-dependency of
init, for instance in init's README.Debian. I'll mention some possible
criteria further down this mail, but those are not part of the committee
consensus (and detailed design work is, constitutionally, not a function
of the technical committee, although some of us might be able to provide
useful suggestions in our personal/non-TC roles, and I have tried to
do so).
It is entirely possible to include init systems in Debian
without being pre-dependencies of init: for instance, at the time
systemd was made available as a non-default init during the wheezy
release cycle, the recommended mechanism to use it was to boot with
init=/bin/systemd. People who are interested in trying new init systems
that are not pre-dependencies of init can do the same, and we would
recommend structuring runit packaging to make this possible if it isn't
already. (For example, systemd was available and worked well in wheezy,
but was most straightforward to test by using init=/bin/systemd; the
systemd-sysv package, which makes systemd provide /sbin/init, couldn't
be installed without applying force until part way through the jessie
release cycle.)
Another way to use an init system that is not a pre-dependency of init
is to override the Important flag and remove init. I think we have a
consensus that we consider this to be a feature, not a bug: it provides an
indication that this particular non-default init system is unlikely to
be suitable for people who do not know for sure that they want it.
We do not consider an init-system virtual package to be a suitable
solution here.
My personal suggestions
-----------------------
As a general operating principle, I think adding a new init system to
the pre-dependencies of init should only be done when the init system is
definitely entirely ready for general use, and has already been tested
on a variety of systems by multiple people (by alternative mechanisms
like booting with init=/sbin/my-init or overriding the Important flag to
uninstall the init package); so modifying init should be the last step in
enabling a new init system. I don't think there should be a presumption
that Debian should consider every init system that has been packaged to be
equally important or equally strongly supported, and if it isn't obvious
that a new init system is ready for wide use, then it probably isn't.
Some criteria that the init-system-helpers maintainers might like to
consider, which I believe are all satisfied by systemd and sysv-rc,
and were satisfied by upstart before it was removed from the archive:
* If the init system is booted in the most obvious way on a simple TUI
system (similar to a default Debian install with Priority: standard
packages), it should start at least one console getty on a VT for
interactive login, without the sysadmin needing to set this up manually.
* It should be possible to configure the init system to provide a getty
on a serial console, for testability on headless servers and VMs,
and it should be documented how to do this.
(systemd makes this very convenient, by starting a getty on the kernel
console by default, and I would encourage this approach. sysvinit is
less convenient here, but does at least have a relatively well-known
way to enable a getty on a serial console.)
* If the init system is booted in the most obvious way on a simple GUI
system, it should be possible to start an X11 display manager and log
in to a simple X11 GUI by merely installing packages, again without
needing manual setup. I think it's fine to have non-default init systems
that don't satisfy the dependencies of major desktop environments
like GNOME and KDE (which need systemd-logind, which in turn needs
systemd), but something like xdm + openbox should always be possible,
and ideally any desktop environment whose dependencies are met should
work without further sysadmin intervention.
* If the init system is booted in the most obvious way on a server with
popular/important server daemons (particularly OpenSSH since that's a
common way to log in, but also things like Apache httpd, Exim, Postfix,
PostgreSQL, dbus-daemon), then those server daemons should work
correctly without further sysadmin intervention.
* As a "lowest common denominator" to enable the majority of services
to work, the init system should be able to run services that are defined
by LSB init scripts, either directly (as sysv-rc does) or by translating
them into its own representation of a service (as systemd does).
* It should be straightforward for maintainers of unrelated packages to
boot the init system on a virtual machine for testing. I see that on
#838480, Martin Pitt suggested an autopkgtest that would codify how to
do this and verify that it works, and I think that's an excellent idea.
* The init system should have a CLI broadly compatible with the common
interface of sysvinit and systemd: reboot, poweroff, telinit and
so on. Unfortunately this is mostly defined by Unix folklore rather
than a formal specification, but comparing the commands provided by
sysvinit and systemd would be a good starting point, and so would
comparing each of sysvinit and systemd with the list of executables
mentioned in the FHS.
I agree with your comment on #838480 that shutdown's time specification
feature is perhaps more complicated than you would want to implement,
but it might be reasonable to consider implementing it so all time
specifications other than 'now' are errors?
* The init-neutral commands in init-system-helpers (invoke-rc.d, service,
update-rc.d) should have their expected functions with the new init
system: as a minimum, they should be able to register and invoke LSB
init scripts. Conveniently, init and init-system-helpers are built by
the same source package.
The init maintainers might also want to consider having weaker criteria
for experimental than for unstable (or conversely, stricter criteria
for unstable than for experimental), so that early adopters can use a
version from experimental.
I don't think that having a mechanism analogous to systemd's "shadowing"
(where a native systemd unit foo.service is used in preference to a LSB
init script /etc/init.d/foo, and is assumed to replace and supersede
the LSB init script) should necessarily be a requirement, but I do think
it's an excellent idea, and I would encourage its use.
I don't think it's wise (or scalable) to expect the init maintainers to
do the work of supporting and debugging non-default init systems. Their
most important role in Debian is to make sure that the init systems of
normal Debian installations work well: in terms of providing the most
benefit to the most users, it is very likely that time they spend on
supporting non-default init systems is less effective than spending the
same amount of time on the default init system. If people want to maintain
alternative init systems then that's great, but the onus should be on
those people to prevent their init system from becoming a burden on the
project - the same way the systemd maintainers spent a lot of time on
system integration work before systemd became a supported init system,
and continue to do so now that it is the default.
smcv
Reply to: