Bug#727708: init dependencies and smooth upgrades from wheezy
I brought this up earlier in the discussion, but it appeared right in
the middle of the big argument about what to vote on, and so seems to
have gotten overlooked. I think this pair of requirements, both
grounded in what it's going to take to do upgrades from wheezy in a
clean fashion, might be a useful alternative to the "L" and "T"
positions that are currently being discussed:
For the release of jessie only,
1. No package may, merely by being installed or upgraded, change the
currently-active init system or the init system that will bring up the
machine on the next reboot. In other words, installations upgraded
from wheezy will continue to boot with sysvinit until the local
sysadmin takes an additional deliberate step to switch to something
else.
[I see this as a vital requirement simply because the sysadmin of any
given installation should have a chance to check over local software,
scripts, etc. to make sure they can handle a changeover. It also
provides a stabilization point after all packages have been upgraded
but before the init system has been changed, which may simplify how
the changeover process works.]
2. Packages may depend on a particular init system in the usual
fashion, but because of (1), must be prepared to cope at runtime if
that init system is not active. Failure to cope is a bug. The
severity of that bug, and the appropriate meaning of "cope" for each
package, are left to the discretion of individual package maintainers
and/or the release team.
[In conjunction with (1), this prevents the formation of "archive
islands" where you can't *install* things just because you don't have
the maintainer's preferred init system active - perhaps for good
reason. But it avoids the equally troublesome situation where
software with a hard dependency can't express that dependency
honestly; it just has to have some sort of runtime check as well - and
that, again, is essential for upgrades to go smoothly.]
[Examples of "failure to cope is a bug": assuming no
unit-file-to-sysvinit-script shim materializes, it would be an RC bug
if openssh-server dropped its sysvinit script prior to jessie.
Similarly for other important network servers. That journal GUI
Josselin mentioned *ought* to be able to display journal-format logs
if pointed to them by name, even if journald itself is not running, so
it has a bug, but if the maintainer wants to call it a wishlist bug
that's fine. It does not make sense to try to run cgmanager and
systemd simultaneously, so cgmanager should detect on startup that
some other (not necessarily systemd) program has control of cgroups,
and if so, bail out cleanly; assuming it does so, it does not have a
bug.]
zw
Reply to: