Bug#727708: package to change init systems
On Sun, Feb 2, 2014 at 1:44 AM, Russ Allbery wrote:
> Cameron Norman 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.
That can be done now with init-select. For example, any package that
requires systemd can currently set /etc/default/init to /bin/systemd,
and tell the user that a reboot is required. It will, however, need
to manually to check that the user hasn't changed the init setting to
something else every time it starts up. That may be as simple as
checking that /proc/1/cmdline is /bin/systemd.
> 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.
If there is no change in default, then we can let users switch inits
as they see fit. We can also watch popcon to see which really become
popular. Users willing to make a non-default init decision are
presumably more capable of dealing with any complications themselves.
> 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.
sysvinit support will not be required for packages that have specific
init dependencies, since the presence of systemd as init can be
checked by those tools that require it. Plus sysvinit support isn't
forever, since eventually it will be deprecated as more and more parts
of the system drop support for it.
Best wishes,
Mike
Reply to: