Hi Steve, On Wed, Apr 01, 2009 at 06:51:29PM -0700, Steve Langasek wrote: > On Wed, Apr 01, 2009 at 08:56:43PM +0200, Patrick Schoenfeld wrote: > > On Wed, Apr 01, 2009 at 06:12:29PM +0200, Michael Biebl wrote: > > > I don't like this idea of RUN=yes variables in /etc/default. > > > > 1.) There is already a documented interface, how to disable a service (i.e. > > > renaming the S?? symlinks for that runlevel to K??). Adding another layer to do > > > this is just confusing and inconsistent. > > > There are tools like sysv-rc-conf which can handle that for you. Enabling a > > > service is then as easy as sysv-rc-conf $service on|off > > > yes, that is true. This concept is however limited in so far that you > > cannot decide before installing a certain service, weither it starts > > after installation. Which is important if you want to avoid running > > wrong/half configured services in your network. Basically the approach > > is just to give some more possible choices to the users. > > All packages should ship with reasonable (--> secure) defaults. Giving > users more choices is not an appropriate substitute; and if we have secure > defaults, giving users more choices should be lower priority. ACK. > That said, if the runlevel editor is appropriately integrated with the > system, it doesn't have to limit itself to waiting for the service to be > installed before setting a policy for the service. The editor could divert > update-rc.d (or otherwise integrate with it), to ensure both that the > runlevel editor always knows the intended policy for the service and that > any global policy set by the admin is respected at the time update-rc.d is > called (i.e., modifying the arguments before passing them to the diverted > update-rc.d). Indeed. Didn't think about the possibility of diversions. I guess diverting the init scripts could be a solution (besides that it needs some further work to the service managing utility). Then I'd whole-heartedly agree with getting rid of RUN_* variables for the sake of consistence. Regards, Patrick
Attachment:
signature.asc
Description: Digital signature