Bug#727708: package to change init systems
Cameron Norman <camerontnorman@gmail.com> writes:
> This is not really what I was interested in. I want a package for each
> init system (init-systemd, init-upstart, etc.) that uses something like
> init-select (under the hood) to prompt the user to change the init
> system. This will allow packages to depend on a certain init being pid
> 1, which is essential seeing as the current TC members seem to be
> leaning towards allowing tight coupling.
More generally, this is going to be required as soon as we have a package
in the archive that provides a daemon and doesn't have a sysvinit script,
pretty much no matter how we get there. Even if we decide on only having
a single init system, we still have upgrades from older systems running
sysvinit to think of. We *might* be able to dodge out of it if we somehow
force the init system switch during a stable release cycle, but even
there, it would be a mess in testing during the transition, and I don't
think it's a good idea to dodge out of it.
Sooner or later, we have to have some way to express the fact that a
particular package only has startup configuration for a specific list of
init systems as a package dependency, unless we think either that (a)
we're going to continue to require all packages with daemons to provide
sysvinit scripts forever, or (b) it's acceptable to install a daemon
package and have it not provide a mechanism to start the daemon.
(b) is probably okay in a few cases, but it's something that Debian has
generally tried to avoid, and I support our current approach that the user
who installs a daemon is asking for that daemon to actually be installed,
configured, and running, not just present on the system waiting for some
additional configuration (unless that's somehow unavoidable). I don't
think our model of "support an init system" should be "when you use this
init system, daemon packages will just randomly not work without any
warning until you notice and write configurations for them." If the
package doesn't provide configuration for a particular init system, that
should be clear from the dependency structure; if the local administrator
wants to install the package anyway and provide their own configuration,
we have well-established mechanisms to allow for that (such as equivs).
I think L is a bad technical design, regardless of the relative merits of
the possible init systems that we might switch to. It's effectively
equivalent to requiring sysvinit support for all packages indefinitely,
and if we thought that was a reasonable design, we would be having a much
different discussion.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: