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?
signature.asc
Description: OpenPGP digital signature
