Patrick Schoenfeld wrote: > Hi, > > 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. > >> 2.) It makes the init script useless. > > That is definitely not true. The init script still stays a common known > interface to control a given service. The idea just adds another layer > of control. And I don't see the need for such an additional layer >> I often install services, which I only need from time to time, so I disable them >> via the approach above and can start them on-demand vi /etc/init.d/service. >> A RUN=no will break that. > > Hu? How should that break it? You do not need to set RUN_<SERVICE>=no, > if you don't want to. You can still disable the service on boot, by > disabling them via sysv-rc-conf and interface with them via invoke-rc.d. So you have two ways now how to disable service, one via the traditional symlinks and the other via RUN_* variables. not a good idea imho >> Imho the only sane option is, to get rid of those RUN_ variables as much as >> possible and advertise tools like sysv-rc-conf more (or even install them by >> default). > > No, because this approach basically does not help anybody. Care to elaborate? > >> There are indeed services though, which should *not* be started by default, as >> e.g. they need to be configured first. But instead of inventing such a RUN_ >> variable, the init script could directly check if its prerequisites are given >> and only start in that case. It then can also output a more sane error message, >> telling the user what it is missing and how he can change that. > > Well, its no invention, becuase the RUN_ variables already exist. They are > just used inconsistent and every init script re-implements the parsing ^^^^^ Definitely not every, some do. And I don't like this behaviour as it doesn't buy you anything. Imo you failed to clearly motivate why we need such an additional layer. I am not convinced yet about the benefits of such an approach. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Description: OpenPGP digital signature