On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote: > I suspect you and I have a root disagreement over the utility of exposing > some of those degrees of freedom to every init script author, but if you > have some more specific examples of policy that you wanted to change but > couldn't, I'd be interested in examples.
It's not necessarily the init script author who might want the degrees of freedom, but the local system administrator. The most basic is the idea that whether you can control (via shell scrpit fragments) whether or not a service should start at all, and what options or environments should be enabled by pasing some file. The fact that we can put that sort of thing in configuration files such as /etc/default/*, for example. Yes, yes, you can do this via if you use system V init scripts scripts in backwards compatibility mode, but you've argued that we should be moving briskly away from that. In which case system administrators will need to hand-edit the services files by hand, which will no doubt increase the chances of conflicts at package upgrade time, compared to if the configuration options were isolated away in files such as /etc/default/rsync (for example). > I realize that > the local administrator may have other goals, and they should have ways of > achieving them, but both systemd and upstart support running SysV init > scripts for those cases. If the package does not ship a SysV init script (which is your ideal long-term outcome), that may not be very practical option for a system adminsitrator who may need to recreate a SysV init script, especially if the service file is rather complicated, or is using some of the more advanced feature of systemd/upstart. - Ted -- 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/20131031015053.gb9...@thunk.org