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 -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MNnznh8CDFFDrYr7qWpo9gPcD8RxB40m=xxotrylzn...@mail.gmail.com