On 2012-07-23 17:59:21 +0100, Roger Leigh wrote: > On Mon, Jul 23, 2012 at 03:26:29PM +0200, Vincent Lefevre wrote: > > No, I just mean that configuration of some service should be > > in a limited number of places. But if you agree that it's fine > > for /etc/default to override config setup somewhere else, then > > there should not be any problem with ENABLE/DISABLE. > > It's not compatible with init systems which do not use the init > scripts directly, e.g. systemd.
I don't understand. If systemd does not use the init scripts directly, how can it be aware of the way to start the daemon? If you want an example, there's wicd-daemon, which just provides an init script and has an ENABLE/DISABLE switch in /etc/default/wicd. > A common interface for enabling/disabling is required, which can > then do the system-specific thing for enabling/disabling. That > should probably be update-rc.d (though the name is > sysvinit-specific). Since we're going to be changing the update-rc.d > interface in wheezy+1, maybe we could simply replace it with e.g. > update-service and provide a compatibility wrapper. And we should > ensure that all init systems provide add/remove/enable/disable > actions. The stop|start actions are going to simply defer to the > "defaults" action, and will ultimately go. A common interface would be nice. But what if there are multiple ways to disable a daemon (as mentioned by Tollef Fog Heen)? I think that it should be flexible enough so that the user can choose. IMHO it should also provide some logging mechanism for add/remove/enable/disable actions. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120723225345.gb8...@ypig.lip.ens-lyon.fr
