Cameron Norman <camerontnor...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- 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/871tzmvws4....@windlord.stanford.edu